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.
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. 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).
Matt.
