cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject New expressions' syntax
Date Fri, 17 Aug 2007 18:15:45 GMT
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/

Mime
View raw message