on 8/23/01 1:08 PM, "Bill Boland" <[EMAIL PROTECTED]> wrote:
> Hi. I am new to this group and I am just learning about Velocity and
> WebMacro and others. I hope the "[PROPOSAL]" heading is correct as I
> have seen others use. I have not posted but once or twice.
Welcome.
[PROPOSAL] is a good title because it implies that you would like to discuss
something rather than requesting a feature or asking for something without
giving a patch to implement it. :-)
> After reading
> though the user and developer's guides and the VTL reference, I was
> wondering if anyone has thought of including...
Another positive, you read the documentation first!
> (1) Providing a way to apply localized formatting to the value returned
> by a reference and/or
> (2) A way to extend the template language through events using the new
> event mechanism.
1
> Again, maybe this has already come up in the past or I'm missing some
> concept (there's a lot to learn) but combining templates with some of
> the concepts in the java.text.MessageFormat class seems like a good
> marriage to allow template authors the ability to provide localized and
> formatted display of their references.
It is easier than that...and more complicated at the same time...you cover
the easy part below, the hard part is determining if the localization of the
templates affect the layout. If that is the case, then you will need to use
not only ResourceBundle style localization but also template level
localization where you duplicate your templates, factor out as much
duplication as you can into velocimacros and then name your templates with
the same syntax as ResourceBundle filename lookup and then use a resource
loader within Velocity which loads the right templates as needed.
> Of course, for many values returned from references, the value needs no
> adjustment. But in the event you are displaying currencies or date
> values, the locale has quite a significant impact on the toString()
> method.
Correct.
> For example, let's say the I have a variable named $now that returns a
> reference to a java.util.Date object that I would like to display using
> a special format. By allowing some optional formatting arguments to the
> reference (example: ${now,date,short} and assuming a default locale
> representing "en_US", the display would be "6/18/01". Of course, a
> different default locale might produce a different result. By also
> allowing a locale value to be assigned to the evaluation of the template
> (maybe as an optional argument to the merge and/or evaluate methods)
> this would allow for great flexibility in the display formatting of
> references. Since it is optional in all of these cases, it would also be
> backward compatible with the existing syntax. Well...I hope you get the
> gist of what I'm looking for and/or proposing.
This particular problem is solved through the use of Tools...
<http://scarab.tigris.org/source/browse/scarab/src/java/org/tigris/scarab/to
ols/Format.java?rev=1.1&content-type=text/x-cvsweb-markup>
Usage in the template looks like this:
$format.date($scarabG.DateFormat, $now)
Turbine also has a LocalizationService which wraps around ResourceBundles to
provide what you need as well.
> Even the locale value could be set at the engine, parse() or expression
> level to allow very flexible formatting and hierarchy. For example:
> ${now,date,short,fr} to format a date in French with the short format.
Wrong syntax, but close...what you do is let the getDateFormat() method
determine the formatting depending on whatever locale criteria you need.
> Currently, I'm providing my own formatting object in the context that is
> used to format the results of other date or currency expressions:
>
> Examples: $format.date( $now, "short" )
>
> The $format object may be assigned a locale and time zone value for many
> different types of formatting (from many of the java.text.* classes)
Bingo. However, embedding "short" is bad...embed a reference to an object
which has a method which will determine the format.
> Also, if an event handler (very similar to the new
> ReferenceInsertionEventHandler) was allowed to look ahead during the
> parsing of the references, then a custom extension to the reference
> could also be applied without even adding this to the official syntax of
> the language. For example, if portion of the reference following the
> variable, method and/or property was provided to the event handler along
> with the reference to the evaluated reference expression, then a
> Velocity developer could extend this as a custom extension without
> changing the code of the base product and provide custom formatting and
> special features (another example: a default values mechanism if the
> return value is null or empty). This might be something like:
>
> public Object ReferenceInsertionEventHandlerEx( String
> reference, Object value, String extraStuff ) throws ParsingException
>
> Using the example syntax above, the parameters might supply the values:
> reference = "${now", value=(a java.util.Date reference) and the
> extraStuff=",date,short"
>
> The event handler would have to interpret the extraStuff and use it to
> return whatever is intended by adding this handler to the engine. But
> there may be a better way to do this by supply a reference to the
> InputStream to allow the developer to parse the stream following the
> reference.
>
> Anyway, I thought by sharing these thoughts that, if warranted, a dialog
> could be establish if others find something like this useful. There
> probably is a better way and having more brain power to examine the idea
> would allow it to blossom or wither away.
IMHO, EventHandlers for rendering are more generic than that...I don't think
they need to be used for formatting dates. They are better used for doing
things like handling cross site scripting vulnerabilities.
Thanks,
-jon
