velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: wrapping XML document as JavaBeans?
Date Wed, 03 Oct 2001 10:30:39 GMT
On 10/3/01 6:20 AM, "Attila Szegedi" <> wrote:

> ----- Original Message -----
> From: "Geir Magnusson Jr." <>
> To: <>
> Sent: 2001. október 3. 11:49
> Subject: Re: wrapping XML document as JavaBeans?
>> No lynching :)  That's neat - I am curious about what 'holds' the XML.  Will
>> go look...
> In a nutshell, Freemarker core does not use reflection on Java objects as its
> data model; instead it expects the objects to implement several interfaces.
> I.e. when an expression is to the left of a dot (say, "field" in
> ""), the engine expects that expression to evaluate to an instance
> of TemplateHashModel interface so it can call the "TemplateModel get(String)"
> method on it with the right-hand side of the dot operator. In a similar
> fashion, when an expression is used in a <list expr as item> construct, it
> expects expr to evaluate to TemplateListModel, and when an expression is to be
> evaluated as a literal (say, it's string representation is to be written to
> the output or used for comparison) then it is expected to implement
> TemplateLiteralModel. There is also a TemplateMethod model for resolving
> "expr(arglist)". And of course, any class is free to implement multiple
> interfaces at once.
> This concept is powerful in that you can have classes implementing these
> interfaces with whatever semantics you need - reflection support essentially
> boils down to being only one special case of possible semantics. XML support
> is just another implementation of these interfaces with its own semantics. As
> you can see, Freemarker sports somewhat different concept than Velocity,
> WebMacro, or Tea (that support method-call-on-objects semantics exclusively)
> so it's an interesting complement in the template engine world to them.

It is interesting - it also constrains access to data/methods/objects, which
has it's upside.  (Really - I'm not being facetious here...)

It's a somewhat academic rather than real-world problem, at least in our
current usage of these tools, but the free access that Velocity and WM
provide does have it's downside in that if you are smart, you can do all
sorts of wacky things that would otherwise be unexpected.

>From what I understand, Tea is also constrained in what you can access.


Geir Magnusson Jr.
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin

View raw message