cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
Date Tue, 14 Aug 2007 09:23:39 GMT
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>> Vadim Gritsenko (JIRA) pisze:
>>
>> Actually, such syntax is supported[1] in our code for almost two years 
>> now.
> 
> The new syntax is supported but it is plugable and the default settings 
> is using the old syntax. I didn't find any detailed design discussion 
> about the design in the archives, the idea is suggested in 
> http://marc.info/?l=xml-cocoon-dev&m=110651769909483&w=2.
> 
> For the actual implementation, the parsing of a string with embedded 
> expression calls (a string template) is plugable using the interface 
> o.a.c.template.expression.StringTemplateParser. The current syntax is 
> handles by JXTGStringTemplateParser and the new one by 
> DefaultStringTemplateParser. The choice of string template parser is 
> done in 
> http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/main/resources/META-INF/cocoon/avalon/cocoon-template.xconf.

> 
> 
> The whole string template mechanism (the package 
> o.a.c.template.expression) could preferably be reused in the sitemap as 
> well. To do this the package needs to be moved to the core 
> (cocoon-expression-language) and refactored a little bit, the 
> dependencies on o.a.c.template.environment.ParsingContext and 
> o.a.c.template.environment.ErrorHolder needs to be removed and a more 
> appropriate package name should be found.

Thanks for bringing this. I'm looking now on this stuff and wonder how we should integrate
old 
sitemap mechanisms. Do I have right impression that I would have to implement StringTemplateParser

for old syntax?

What makes me wonder is that ErrorHolder class. I really don't understand it's purpose and
our 
archives don't help in this case.

ErrorHoler is used when is caught java.lang.Error so it's stored in ErrorHolder this class
is 
rethrown. According to javadocs:

   An Error is a subclass of Throwable that indicates serious problems that a reasonable application
   should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error,
though a
   "normal" condition, is also a subclass of Error because most applications should not try
to catch
   it.

this exception should be never caught. What's the secret here?

>> To sum up, new syntax has been introduced during refactoring of 
>> Template block and since community already voted to switch to 
>> refactored code it also voted for new syntax.
> 
> The vote was not about removing the current syntax. It was about 
> switching default implementation of the JXTG concept.

You are right, I misinterpreted things.

> 
> Using the string template mechanism in the sitemap we get the current 
> JXTG syntax for free, but I would advice users to not use it.

What about deprecating?


> I'm all for recommending using the new unified expression mechanism and 
> for having a migration guide. But I'm -1 for forcing people to switch 
> immediately, especially as we already have a mechanism for making the 
> syntax plugable.

I understand your concerns and I agree it should be quite easy to reuse existing mechanisms.
The 
only doubt remains is about ErrorHolder.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection                ***
*** incessantly so I'll not be able to respond to e-mails                     ***
*** regularly and my work will be somehow irregular.                          ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***

Mime
View raw message