Leszek Gawron wrote:
Daniel Fagerstrom wrote:
No, I use faulty terminology, I didn't mean expression parser but
rather string template parser (or whatever we should call it).
For those who don't remember the discussions (which seem to include me
and me :)
<snip/>
Thanks for such a good summary. One more thing though. Did we happen
to establish some pluggable expressions supporting convertors syntax?
The original thread is here
http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2 and it is quite
long so I have not had time to read all of it, but I don't think we
established a syntax.
I mean something like:
{wikify:jexl:myString?locale=a&wikiRenderingEngineParam=2}
(gosh that's ugly :))
Don't know if we should go that far. The main application for plugable
coverters (within templates) is to convert a (simple) Java data type to
a string representation in the current locale, so a typical example does
not need any syntax at all:
{jexl:myFloat}
in some cases one want to be able to chose among several different kinds
of conversions, one might want to have a short and a long format for
numbers e.g., the idea was to solve that with different classes of
convertors Jonas Ekstedt proposed:
{jexl:myFloat#short}
i.e. fragment syntax for URIs
(http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#fragment), IMO that
makes sense as:
"The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary
resource and additional identifying information. The identified
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or some
other resource defined or described by those representations."
A specific class of convertors gives a "view on representations of the
primary resource".
I don't think we should start to have parameters to the converters and
so on, if you need more "programming" in your templates you can write
java code and call it from Jexl or JXPath. Convertors is intended to
decrease the need of programming in templates and have a more
declarative solution there typical conversion patterns allready are
predefined.
I'm also somewhat negative to have convertors that creates XML as some
people have suggested, I can understand that it can be useful in some
cases, but it makes the concern area for convertors more blurred and
complicates the architecture.
Lets start simple with the convertors.
/Daniel