14 messages in org.kde.quanta-develRe: Quanta 3.3 plans
FromSent OnAttachments
Eric LaffoonJan 21, 2004 12:52 am.kno
Chris HornbakerJan 21, 2004 4:37 am 
Bill ChmuraJan 21, 2004 7:17 am 
Andras MantiaJan 21, 2004 7:43 am 
Andras MantiaJan 21, 2004 7:56 am 
Linus McCabeJan 21, 2004 8:25 am 
Andras MantiaJan 21, 2004 8:42 am 
Chris HornbakerJan 21, 2004 9:29 am 
Eric LaffoonJan 21, 2004 12:12 pm 
Eric LaffoonJan 21, 2004 1:14 pm 
Melvyn SopacuaJan 21, 2004 2:30 pm 
Eric LaffoonJan 21, 2004 11:53 pm 
Nicolas DeschildreJan 22, 2004 5:00 am 
Andras MantiaJan 22, 2004 6:36 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: Quanta 3.3 plansActions...
From:Melvyn Sopacua (md@idg.nl)
Date:Jan 21, 2004 2:30:21 pm
List:org.kde.quanta-devel

On Wednesday 21 January 2004 16:57, Andras Mantia wrote:

3. KHTML: someone who knows a little shell scripting, XSLT and such may come up with an example how to turn an XML to HTML and view it in Konqueror. After that it's easy to integrate that in Quanta. Chris?

You can't do that generically. The best you can do with that is to provide a clickable tree, like IE does. If I may take XML Spy as an example - it has a button "Associate with XSL sheet" for XML documents, which presents you with a path dialogue, then makes that the stylesheet PI in the XML document (See Chris' mail). Things it did wrongly: * No option to use relative paths, which meant once you uploaded it referred to none-existing paths. * No option to strip the stylesheet PI when uploading - some files are parts of larger documents via x-include or similar technologies, where the stylesheet is set in the main doc, but while developing the smaller documents it's nice to have a preview. This is something Quanta's project system could handle.

The other way around also works, with one major difference, is that there is no tag support to associate a stylesheet with an XML document, so on a project level, an XML document can be specified which should be used as an "example document for transformation". Nice to have: specifyable on a directory level within a project.

Last but not least, you need to be able to specify the XSLT processor to use, because for instance Sablotron has JavaScript support for E-XSLT, SAXON tends to be more practical than strict etc. It is very important, that developers can run the transformation with the software they use on the live website.

So what you would need is a dialogue to register a processor for preview transformation, and provide documentation, clarifying that "$1" will be the path to the XML document, $2 the stylesheet and that output is expected to be written to stdout. People who work with this stuff, should be smart enough to read manpages and provide the right information, but a set of defaults for xsltproc, Saxon and Sablotron would help. Nice to have: option to provide a toolbarbutton per registered processor.