Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 9568 invoked from network); 17 Aug 2007 00:25:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Aug 2007 00:25:33 -0000 Received: (qmail 68181 invoked by uid 500); 17 Aug 2007 00:25:30 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 68104 invoked by uid 500); 17 Aug 2007 00:25:30 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 68093 invoked by uid 99); 17 Aug 2007 00:25:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Aug 2007 17:25:30 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [216.86.168.179] (HELO mxout-04.mxes.net) (216.86.168.179) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Aug 2007 00:25:22 +0000 Received: from [192.168.0.129] (unknown [80.240.191.89]) by smtp.mxes.net (Postfix) with ESMTP id 3C5B9A3209 for ; Thu, 16 Aug 2007 20:25:00 -0400 (EDT) Message-ID: <46C4EAB8.8010308@apache.org> Date: Fri, 17 Aug 2007 02:24:24 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine References: <21426584.1186796862562.JavaMail.jira@brutus> <46BD7FDB.4040105@apache.org> <46BD988F.4060901@nada.kth.se> In-Reply-To: <46BD988F.4060901@nada.kth.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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. > > ... >> 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. > >> Speaking about myself I prefer much more language prefixes and I think >> we should go for it. The question that we need to answer is if we want >> to support #{} syntax in sitemap? Since it was never there I don't >> think it makes sense to do so. > > 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. Daniel, I implemented what you proposed but not committed yet due to regression it introduces. Basically, I implemented handling of sitemap expressions in LegacyStringTemplateParser (JXTGStringTemplateParser in the past) and it's seems to work ok with basic tests. However, LegacyStringTemplateParser is also used in Template block so, as result of my changes, one will be able to evaluate sitemap expressions in templates. It's not that bad but it introduces small regression. With old implementation of JXTGStringTemplateParser it was possible to escape "{" character but not mandatory. With new implementation it's mandatory because it will be parsed as sitemap expression otherwise. I tried to search for all occurrences of such unescaped "{" with this command: find | xargs grep "http://apache.org/cocoon/templates/jx/1.0" -l | xargs grep -E "<\?xml" -l | xargs grep -E "[^#\$][{]" -l | grep -E --invert-match ".svn|target" and got following results: ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/dreamteam/content/teamTemplate.jx ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/file_explorer_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/inplace_edit_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/datasource_chooser_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/dynamicrepeater_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/sampletree_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/xmlresult_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/carselector_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/multipage_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/xdoceditor_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/tasktree_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/dynamicrepeater_dojo_template.xml ./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/dynamicrepeaters_dojo_template.xml ./blocks/cocoon-template/cocoon-template-sample/src/main/resources/COB-INF/view/caching2.jx ./blocks/cocoon-template/cocoon-template-sample/src/main/resources/COB-INF/view/caching3.jx ./blocks/cocoon-template/cocoon-template-sample/src/main/resources/COB-INF/view/caching1.jx ./blocks/cocoon-template/cocoon-template-sample/src/main/resources/COB-INF/view/caching4.jx ./blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/macros/timedbrowserupdater.xml Not that much files to fix on our side but I'm wondering about our users. What do you think? Can we go on with such regression? -- 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. ***