[stringtemplate-interest] format="random string" harmful
Kunle_Odutola at hotmail.com
Thu Oct 12 03:25:56 PDT 2006
Didn't get Ter's original message for some weird reason... ??
> On Sun, Oct 01, 2006 at 02:57:30PM -0700, Terence Parr wrote:
> > Hi,
> > I just realized that allowing the random format string to dictate
> > which function to call on some formatter object is way too big of a
> > whole. It is the same thing as velocity that allows you to pass in a
> > model and call random methods on it. Imagine:
> > $"select * from Users"; format="query"$
> > weird, but would call renderer.query("select * from Users"). Pass in
> > a DB object and we have a problem.
That problem already exists. AttributeRenderers can be misused.
> > I think that I need to stay probably with a predefined set of
> > useful functions that you can apply to attributes.
That simply defers the custom formatting issue until someone needs a format
that isn't predefined. ST *still* needs a mechanism that enables a "View
Framework Developer" to support arbitrary rendering/formatting requirements
without violating model-view separation.
> "Standard formatting" limited to which of the following:
> * Capitalization, all/ partial/ first/ last.
> * MAC & IP address formatting functions.
> * Time & Date and TimeDate formatting.
> * Brief/Full Hereford (cattle) Statistic formatting.
> * CPU Model+Stepping+Manuf+...
> * ...
> There are two things needed here:
> 1) What criteria to decide which built-in formatting functions.
The 80/20 rule?. Include as many as we can of those functions that covers
the needs of 80% of applications.
> 2) What to tell people to do when they want something extra.
Hopefully, it will be to use ST's (to-be-developed) custom formatter API:
e.g. $ip_name; format="ipaddress"$
public static class MyModelRenderer implements AttributeRenderer
public String toString(Object o)
public String ipaddress(Object o)
More information about the stringtemplate-interest