xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fo...@neonics.com
Subject Re: XSP outside of Cocoon
Date Thu, 14 Mar 2002 17:10:11 GMT


> Ah ok, I get it, have to reconfigure my brain to think XSLT all the way :-)

hehe ;)

> [example]
> 
> Yeah, I see the point, it can be done with XSLT. But: is it a good idea
> to do it with XSLT? I see the elegance of that approach, but it's also a
> little kludgy to maintain and probably a bit on the slow side, too. I

Wel, you need to cache the generated class file ofcourse, because it takes
a few seconds to generate/compile it (even with cocoon).

> don't think it is a particular advantage to have your transformation in
> an XSLT stylesheet when it looks like this:
> 
> <xsl:template match="mytaglib:myfunction">
> 	<xsp:logic>
> 		... yaddayadda 500 lines of Java code ...
> 	</xsp:logic>
> 	<result>
> 		<xsp:expr>mystring</xsp:expr>
> 	</result>
> </xsl:template>

> I think this is poor usage of XML. You just wrap your Java code in angle
> brackets, it's like saying "my application's configfile is now written
> with angle brackets, yay, I support XML". This is just
> buzzword-compliance :)

The idea is that you don't actually put ALL your code in 'angle brackets',
just separate functions, or, better, just function calls.
The code itself should be in some library, and you just call it.
So, whenever your code is independent of the xml-source, you should
put it in some utility class or library, so it won't have to be
recompiled each time your xml file or xsp page changes.

My configfiles are indeed in XML, but it uses a tree structure,
which is impossible with a flat file. I use XPath expressions to retrieve
the values, or lists of values, so if you use these features then you
are better off using xml.

And indeed, some people are abusing the term 'xml compliance' :)

> Something like the above does not need XSLT-processing to be transformed
> into Java. You can simply copy the 500 lines of Java code verbatim and
> then add:
> 
> contenthandler.startElement("result");
> contenthandler.characters(mystring);
> contenthandler.endElement("result");

Indeed. However, if you choose this approach, all you can easily do is
create an xml file with just one root tag. As soon as your document
structure becomes more complex, you will have to put a lot of effort into
coding the java file. It's also more sensitive to bugs.

I agree that you shouldn't always generate the source files runtime,
but you could use the xslt techniques to generate a java source,
and add that source into CVS or something and never regenerate it again.
It might save you a lot of work.

> Well, if you make use of XSLT constructs in your taglib definitions,
> like <xsl:for-each> or <xsl:apply-templates>, then it begins to make
> sense. I've noticed with the taglibs I wrote for Cocoon1, that it is a
> trade-off. Sometimes you can do very elegant things like in the esql
> taglib - that is a good example for a declarative concept and
> declarative concepts mostly look good in XSLT.

You should look at it from another point of view.

Say you have a static website, with a lot of html pages.

In some of the pages you would like to insert some dynamic content
(even if it is just a time-of-day string).

You could do this easily with PHP or JSP.

But, if you would like to change the layout of your site, you would
have to edit ALL the html files.

So here comes the use of XSLT: define the content in XML and have a XSL
file to define the layout of your site.

If you want to change the layout, just edit the single xsl file,
and the layout of your entire site changes with it. You can even
have multiple layouts for the same site.

I think you'll agree that this use of XSL/XML is usefull: some XML
files with the site content, and one (or more) xslt files.

If you already have this structure, why not add the possibility of
inserting dynamic content? Its very easy, just insert a tag in your
XML files (or even xsl, although that's not possible with cocoon)
that evaluates to the content you would like to have dynamically
generated.

This all makes sense.

But you should use it carefully, and not abused in the way you described
(creating an xsp page with 500 lines of code in it).

As with all flexible technologies, they can be used in ways not intended.
If you're a good designer (program designer, not graphics), you can see
how to optimally use this technology to make your life easier.


> On the other hand, if you have a taglib that is supposed to send off a
> mail, then there is nothing declarative about the process. You need a
> template and pass it the FROM, TO, SUBJECT, BODY parameters and off you
> go. The same thing applies for adding the "extra syntax" in transforming
> XSP pages to Java classes: like class declaration and imports - it's not
> a particular advantage to do this in XSLT, it's a simple copy&paste operation.

Indeed. what we have here is the use of some library function you wish to
encorporate in your website. There are several ways of doing this.
All you really need is some code that calls that library function
with some parameters, possibly passed to the webserver with a GET/POST
operation. So you should make the code that calls that application
as easy as possible, using as few lines as possible.


> So, I'm not 100% decided yet whether the transformation from XML to Java
> should be done with XSLT.

If you consider doing XML to Java conversion anyway,
why shouldn't you use XSLT? If you wouldn't, you would have to write
some function that reads the xml file, and transforms it to java.
Why re-invent the wheel when XSLT is available to do the job?

Just because XSLT is able to do so much more than inserting 500 lines
of java code in some document, isn't a reason not to use it.

> > Well, you can also generate the Swing components if you want to. You
> > then need to edit the final xsl, to not produce SAX events (since you
> > cannot runtime edit sax events into swing-java-code (at least not very
> > fast), but to generate a java file that is your final goal.
> 
> Absolutely. But if we decide on Swing GUIs, I'll have to think about
> whether using a good IDE wizard wouldn't be more productive...

Yeah... you should only use XSLT if you would have to regenerate the
source files from time to time, and if it would be less work to use
XSLT than to use some IDE.

Again, you always need to choose the option to use on several criteria,
for example:

1) Maintainability (if this and that change was necessary, how much
			work would it be using either XSLT or an IDE)
2) Ease of use 
3) ... you can think of some more ;)
 
> > However, cocoon 2 is a lot faster, since it uses the SAX events as I
> > described above. It uses a complete different core, also removing the
> > stylesheet-directives from the xml files and moving it into a 'sitemap',
> > which defines what needs to be done when some url is requested.
> 
> Using SAX events is a great idea in cocoon2 and I see no reason not to
> copy this idea. The sitemap, well, that's one of the things I don't like
> in cocoon2. Undoubtedly it's a masterpiece of software engineering and I
> would probably never be able to come up with such a complex design and
> actually make it work. Therefore I admit that I am not very qualified to
> talk about it, but it's a free world, right? :)

Heheh.. i myself just use a configfile with a sitemap in it and examine it
runtime. No need to convert that into java sourcecode.

You could convert ALL config files into java code, but what's the use?
Say you create a java file for /etc/passwd, which has a few functions like
userExists(String) and the like.. Does it have advantages over coding
such a function yourself which reads the original /etc/passwd?


> For me the sitemap is a good example for buzzword-compliance with XML.
> There is nothing declarative about it, it's just a configfile like
> httpd.conf, which happens to be written with angle brackets. It contains
> expressions that are unknown in XPATH. Additionally, I don't think it is
> advisable to put application logic into a central configfile.

Well.. if you would convert the sitemap to java, and you CAN use xslt,
then you HAVE to use an XML file as the source. That's why they chose XML.

Next, you don't have to use XPATH expressions in an XML file.
You can use XPATH in XSLT or in some java class to get values from an XML
document.

> And the concept, well, imagine moving one of your apps from one Cocoon2
> installation to another. You have to move parts of the sitemap with the
> application and I can imagine that in any reasonably complex
> installation afterwards neither the moved application, nor the ones left
> behind will work.

It's better to have a sitemap as a central file than to spread it all
across your xml documents, which is hard to maintain.

I have improved the sitemap a bit. I use regular expressions on the URL
so I can decide which source file (xml) and which transformations should
be applied. The site structure on disk does no longer have to comply
with the URL structure the end-users see (this is also a feature of Cocoon
2).

You can also choose to use different stylesheets on the same XML document
depending on a lot of variables, for instance the URL (for example,
if you prepend debug/ to the URL, you can skip the final XSL
transformation
and see what the final XML file looks like). Also you can use different
suffixes to determine the file format sent back (.html, .text, .pdf for
xml files, .svg, .gif, .jpeg for graphic files).

If you use the old cocoon 1 method, you would have to put this logic
of determining what file format the document should be transformed to
into preprocessing directives, spread all over the documents.

With the sitemap, you can separate the real content, the  stylesheets
and the logic and manage them more easily.

The situation described above, when you want to change the layout of your
entire site, will have a lot of impact on the amount of time you have
to spend. You would have to edit each and every XML file present
in your site (if you use cocoon 1), in stead of just changing one line
of the sitemap. Ofcourse you can always overwrite the old xsl file
with the new one, but there are more complicated situations which show
that the sitemap solution saves you a lot of work.

> For me the sitemap is spelled "N-I-G-H-T-M-A-R-E", but I'm sure a smart
> developer can leverage its power. However, I dream of something that is
> as dumb as I am :)

;)

Always choose the option that saves you a lot of work, that's my motto.


Greetings,

	Kenney Westerhof


Mime
View raw message