Sylvain Wallez wrote:
Leszek Gawron wrote:

Sylvain Wallez wrote:

This is an interesting idea, which could be even more useful if the convertors were able not only to produce strings, but also XML snippets for output-only data. For example, we may want an email address to be rendered as a <a href="mailto.."> or negative numbers being displayed in red, or enclosed in parenthesis.

What that means is that a convertor should be able to do the following conversions:
- string+locale --> object : parsing request parameters
- object+locale --> string : producing the value of an input
- object+locale+channel --> xml fragment : producing the output view for a particular channel (html, wap, fo, etc).


If I would be able to choose convertors in the template (I mean on the same page render model entry in plain text and pretty printed) it would solve a LOT of my rendering problems. If convertors were pluggable I could also choose which convertor I would like to use in template itself.

Lovely

:-) More polish beer!!!
Apparently. Would you like to wait for whole 6-pack or should I send it one-by-one? :)

Or a more traditional function-like syntax: ${convert(expression, optionalHint)} (the "optionalHint" allows to choose a convertor other than the default one).
simpler to implement and still fully functional.

--
Leszek Gawron                                      [EMAIL PROTECTED]
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



Reply via email to