Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (nike.apache.org: domain of grek@tuffmail.com designates
 216.86.168.179 as permitted sender)
Message-ID: <46C5E5D1.3050305@tuffmail.com>
Date: Fri, 17 Aug 2007 20:15:45 +0200
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20070728)
MIME-Version: 1.0
To: Cocoon's dev mailing list <dev@cocoon.apache.org>
Subject: New expressions' syntax
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I would like to discuss a new syntax for expressions or more precisely for string templates that are 
going to be default in Cocoon.

In order to clarify things I'll provide vocabulary that corresponds to current implementation.

   Expression
     Expressions are just strings that can be interpreted in certain language like Jexl or JXPath.
     Expressions can contain prefix that gives hint how to interpret them. Some examples:
       * jxpath:$cocoon/request - JXPath
       * bean.HelperMethod("sth") - Jexl
       * ${bean1.bean2} - this is _not_ an expression (more below)

   String template
     String templates are strings that contain both expressions (wrapped in some special characters)
     and literals mixed up. Examples:
       * This is literal, #{$cocoon/request}. - literal and JXPath expression wrapped in old way
       * ${bean1.bean2} - only Jexl expression wrapped in old way
       * Literal1 {request-param:param} Lieteral2 - two literals and sitemap expression wrapped using
                                                    {} characters.

In this mail I would like to discuss these wrapping characters for string templates we are going to 
have by default at least in Template and Sitemap but very likely that also in Forms and other places 
where expressions can be useful.

Currently we use {} to wrap sitemap expressions. We use #{} to wrap JXPath, ${} to wrap Jexl, @{} to 
wrap Javascript expressions, all in Template only.

One of my big goals is to make you think only about one string template, one wrapping chars and 
whatever you like number of expression languages you like everywhere in Cocoon. When achieving this 
goal I must keep back-compatibility in mind all the time as Daniel is patiently reminding me.

I think that I have not introduced any back-incompatibility so far even I wanted several times. I 
guess it's the hardest time because I'm I want to:
   a) allow people migrate to new expressions both in Template and Sitemap smoothly
   b) stay 100% back-compatible with old code behaviour while implementing new ways of expression 
evaluation and most importantly Object Model construction
   c) avoid confusion about what's new and what's old

This leads us to small but very important question: how we wrap new expressions? If I'm not wrong, 
current preference  has been to wrap new expressions in {}, Daniel confirms[1] this view.

My own opinion is that plain {} are ok in sitemap but will not work well in general. If choose {} as 
wrapping characters everything put between this characters will be considered as expression. If you 
additionally remember that all strings inside elements are treated as String templates you may start 
to be warned. Take a look this[2] file's snippet:

   <style type="text/css">
     #files { border-collapse: collapse; border-left: dotted black 1px; }
     #files td { padding: 0.1em; border-bottom: dotted black 1px; }
     .selected { background: #D0D0D0; }
   </style>

It's a content of jx template but obviously we don't want generator/transformer to interpret this 
CSS declarations as Cocoon expressions! We would need to escape {} wrapping characters:

   <style type="text/css">
     #files \{ border-collapse: collapse; border-left: dotted black 1px; \}
     #files td \{ padding: 0.1em; border-bottom: dotted black 1px; \}
     .selected \{ background: #D0D0D0; \}
   </style>

It's ugly, don't you think?

Next choice could be to use ${}. The problem with this characters is that they are already used in 
Template and if we don't pick Jexl language as default it will break current templates not to 
mention confusion it would cause. We could come up with %{}, !{} or whatever is not used yet. 
Everyone's keyboard has lot of remaining symbols waiting for use but I wonder if we really want/need 
new wrappers.

I'm stuck. Thoughts?

[1] http://marc.info/?l=xml-cocoon-dev&m=118703810504930&w=2
[2] 
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/file_explorer_template.xml

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/