You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Christopher Oliver <co...@mminternet.com> on 2002/04/02 11:00:48 UTC

Re: plug this

Hi Geir,

I was just in the process of hacking Velocity for use with JavaScript
(Rhino http://www.mozilla.org/rhino) when I noticed your post. I did
this so I can drive Velocity from JavaScript and use JavaScript objects
as well as Java objects in Velocity templates, for example in the below
script.

var velocity = new Velocity();
velocity.init();

var object = {
    name: "Chris",
    address: {
        street: "404 Huntington",
        city: "Monrovia",
        state: "CA",
    },
    date: new java.util.Date(),
}

var result =
    velocity.evaluate(object,
        "$name worked at $address.street on $date.toString()");


This script prints out (as you might expect) "Chris worked at 404
Huntington on Tue Apr 02 00:34:22 PST 2002".  To make it possible to
call JavaScript functions I had to hack in my own introspector.  I have
placed the source and compiled code on my ftp server
(ftp://ftp.primaryinterface.com/pub/rhino/vel-js.zip) if anyone is
interested in looking at it.

I could use your new pluggable introspector interface instead if you
could make one change, namely to pass the target object to the
introspector rather than only its class, e.g.

    public VelMethod getMethod(Object target, String method, Object[]
args, Info info) throws Exception;

instead of

    public VelMethod getMethod(Class cls, String method, Object[] args,
Info info) throws Exception;

Obviously the standard introspector could still be implemented under
this interface.

Best Regards,

Chris


>            From: Geir Magnusson Jr.
>            Subject: Plug this...
>            Date: Tue, 26 Mar 2002 00:39:08 -0800
>
>
>       On my jakarta account
>
>       http://jakarta.apache.org/~geirm/vel-pluggable.tgz
>
>       You can find a source tree that has pluggable introspection.  All of the
>       current introspection has been brought into one place, and Velocity need now
>       just one interface to do that.  Look into o.a.v.u.introspection
>
>       I tried to balance the needs of the plug-intro writer to have all sorts of
>       wacky freedom to do what they wish, versus the intense desire to keep things
>       protected (i.e. Velocity makes the decision to do the set/get rather than
>       the plug-intro)
>
>       So if you were interested in this subject (Paulo, Christoph, Peter) take a
>       look.  Daniel's ideas about what should happen in Foreach can be done
>       through this as well, I would imagine, so he should be happy.
>
>       It works against the testbed - if people think its ok, I'll commit and
>       remove the iterator from the RuntimeInstance, as it would have no futher
>       purpose - this will require simple changes to the testbed, but not major
>       ones...
>
>       --
>       Geir Magnusson Jr.                                     geirm?X0040;optonline.net
>       System and Software Consulting
>       "They that can give up essential liberty to obtain a little temporary safety
>       deserve neither liberty nor safety." - Benjamin Franklin
>
>
>
>       --
>       To unsubscribe, e-mail:
>       For additional commands, e-mail:
>
>
>
>            Plug this..., Geir Magnusson Jr.
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: plug this

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
That's really cool.

The request is reasonable - I had originally done it with Object rather than
Class for all of them, but switched for some reason that was incredibly
obvious at the time.  But there should be no problem switching...


On 4/2/02 4:00 AM, "Christopher Oliver" <co...@mminternet.com> wrote:

> Hi Geir,
> 
> I was just in the process of hacking Velocity for use with JavaScript
> (Rhino http://www.mozilla.org/rhino) when I noticed your post. I did
> this so I can drive Velocity from JavaScript and use JavaScript objects
> as well as Java objects in Velocity templates, for example in the below
> script.
> 
> var velocity = new Velocity();
> velocity.init();
> 
> var object = {
>   name: "Chris",
>   address: {
>       street: "404 Huntington",
>       city: "Monrovia",
>       state: "CA",
>   },
>   date: new java.util.Date(),
> }
> 
> var result =
>   velocity.evaluate(object,
>       "$name worked at $address.street on $date.toString()");
> 
> 
> This script prints out (as you might expect) "Chris worked at 404
> Huntington on Tue Apr 02 00:34:22 PST 2002".  To make it possible to
> call JavaScript functions I had to hack in my own introspector.  I have
> placed the source and compiled code on my ftp server
> (ftp://ftp.primaryinterface.com/pub/rhino/vel-js.zip) if anyone is
> interested in looking at it.
> 
> I could use your new pluggable introspector interface instead if you
> could make one change, namely to pass the target object to the
> introspector rather than only its class, e.g.
> 
>   public VelMethod getMethod(Object target, String method, Object[]
> args, Info info) throws Exception;
> 
> instead of
> 
>   public VelMethod getMethod(Class cls, String method, Object[] args,
> Info info) throws Exception;
> 
> Obviously the standard introspector could still be implemented under
> this interface.
> 
> Best Regards,
> 
> Chris
> 
> 
>>            From: Geir Magnusson Jr.
>>            Subject: Plug this...
>>            Date: Tue, 26 Mar 2002 00:39:08 -0800
>> 
>> 
>>       On my jakarta account
>> 
>>       http://jakarta.apache.org/~geirm/vel-pluggable.tgz
>> 
>>       You can find a source tree that has pluggable introspection.  All of
>> the
>>       current introspection has been brought into one place, and Velocity
>> need now
>>       just one interface to do that.  Look into o.a.v.u.introspection
>> 
>>       I tried to balance the needs of the plug-intro writer to have all sorts
>> of
>>       wacky freedom to do what they wish, versus the intense desire to keep
>> things
>>       protected (i.e. Velocity makes the decision to do the set/get rather
>> than
>>       the plug-intro)
>> 
>>       So if you were interested in this subject (Paulo, Christoph, Peter)
>> take a
>>       look.  Daniel's ideas about what should happen in Foreach can be done
>>       through this as well, I would imagine, so he should be happy.
>> 
>>       It works against the testbed - if people think its ok, I'll commit and
>>       remove the iterator from the RuntimeInstance, as it would have no
>> futher
>>       purpose - this will require simple changes to the testbed, but not
>> major
>>       ones...
>> 
>>       --
>>       Geir Magnusson Jr.
>> geirm?X0040;optonline.net
>>       System and Software Consulting
>>       "They that can give up essential liberty to obtain a little temporary
>> safety
>>       deserve neither liberty nor safety." - Benjamin Franklin
>> 
>> 
>> 
>>       --
>>       To unsubscribe, e-mail:
>>       For additional commands, e-mail:
>> 
>> 
>> 
>>            Plug this..., Geir Magnusson Jr.
>> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
The bytecodes are language independent. - Sam Ruby  


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>