On 3/14/02 2:53 AM, "Christian Trutz" <[EMAIL PROTECTED]> wrote:
>
>
> [SNIP]
>> I disagree, you're going to get into all the nasty problems of
>> generating source and compiling the sources in your deployed
>> environment.
>
> OK, I don't have experience with such problems ...
>
> [SNAP]
>> I have thought about it a lot but haven't done much. Also realize that
>> with the current internal structure of velocity it is not possible to
>> make an efficient compiler because the types of the objects in the
>> context are not assumed to be static. By that I mean if you 'person' in
>> the context, during one rendering that can be a Person object, but on
>> the next it can be a Hashtable.
>
> Oh, I think, it doesn't matter if $person is a Person or a HashTable, why
> it's not correct to handle this like:
>
> ...
> Object person = context.get( "person" );
> writer.write( person != null ? person.toString() : "$person" );
> ...
That's fine - that's the simple case though. If I have
$person.foo
Velocity is required to try
$person.get("foo")
$person.getFoo()
$person.getfoo()
$person.isFoo()
Of course, you can express that easily in bytecode (lets face it, our code
compiles... :)
This feature is very valuable in separating the view expressed in the
template from the datamodel expressed as objects in the context...
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
The bytecodes are language independent. - Sam Ruby
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
