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&amp;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

Reply via email to