But in fact it seems like XSP is being disliked by many developers. And I have to admit: I don't really like much anymore, too. But the question is whether it is because of the syntax or the heavy machinery or it's maintainability.
IMO it's obvious: the mixture of coding languages (Java + XML) and the mixture of abstraction levels. But this abstraction does not make the coding easier, you have to know the implementation details to work around all possible mistakes: How often it is suggested to have a look at the generated Java files! In general we need a XML only XSP (i.e. without any Java written by hand) with minimum of flow support:
<xsp:if>, <xsp:for-each>, etc.
This level of change to XSP should be discussed on [EMAIL PROTECTED], fwiw. I personally would be against this kind of logic control in XSP. Especially since it's perfectly possible to add this in as a tag library.
I thought this list was dead and removed? Is there any archive available about recent discussions? But I understand your concern as Cocoon is not the only XSP implementing project.
But I don't understand your concern related to this logic control. At the moment you can do everything using the implementing language Java or JavaScript or Perl or what ever. The above "proposal" would bring this to a standardized way. It's also in XSLT that I had in mind when writing the above.
There is also an example on Axkit's XSP guide (http://axkit.org/wiki/view/AxKit/XSPGuide):
<xsp:logic>
if (somecondition()) {
<xsp:content>
<true_tag/>
</xsp:content>
} else {
<xsp:content>
<false_tag/>
</xsp:content>
}
</xsp:logic>which can be simplified to
<xsp:when test="somecondition()"> <true_tag/> </xsp:when> <xsp:otherwise> <false_tag/> </xsp:otherwise>
(By the way, the simplification to
<xsp:logic>
if (somecondition()) {
<true_tag/>
} else {
<false_tag/>
}
</xsp:logic>is exactly what does not work at Cocoon and was the reason for the problem at http://marc.theaimsgroup.com/?t=106931803600003&r=1&w=2.)
Yes, afterwards it's very similar to XSLT or other template languages as JXTemplate.
The power of XSP is not XSP itself, but the further abstraction levels as esql as Leszek pointed out. This would make an XML only XSP to a really powerful template language in contrary to a programming language with nasty syntax at the moment.
This isn't XSP's fault that it gets (ab)used this way. It's perfectly possible *today* to write XSPs that have no programming code in them.
Might be, but the easier the abuse is, the more it will be abused.
If Cocoon makes that hard I would consider it a bug (or at minimum a required feature for making XSP a reasonable framework to work with). Certainly it's very easy in AxKit - you just create a class and tell AxKit what methods are tags (sort of like SiLLy, but easier).
Do you have an example? The XP guide is really short.
Joerg
