cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <jheini...@virbus.de>
Subject Re: XSP "official" position
Date Sat, 22 Nov 2003 01:56:14 GMT
On 19.11.2003 10:13, Matt Sergeant wrote:

>>> 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 
> xsp-dev@xml.apache.org, 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


Mime
View raw message