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