cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
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 
> 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 

> 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
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
archives don't help in this case.

ErrorHoler is used when is caught java.lang.Error so it's stored in ErrorHolder this class
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

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.
only doubt remains is about ErrorHolder.

Grzegorz Kossakowski
*** 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. ***

View raw message