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/
