Adapting Beanlike Non-Beans for use with Velocity

[Eric Fixler <fi...@fixler.com>]

Hello.  I'm working with a couple of packages that return data records 
in a Map-like format, but they're not Maps, and not beans.  (One of 
these is Lucene, with which some of you are likely familiar)

Roughly speaking, instead of using the setXxx and getXxx pattern, these 
packages use calls like document.getField("xxx") and 
document.setField("xxx",value).

I'm wondering if the bean introspection layer of Velocity has any 
mechanism whereby I could write an adapter class, with the ultimate 
goal being the use of these classes (or Maps, for that matter) just 
like regular old Java Beans in Velocity template, i.e. the adapter 
class would generate the mapping so that $object.property would call 
document.getField("xxx") instead of document.getXxx.

Any pointers greatly appreciated.  If this doesn't exist, seems useful 
to other people, and I manage to do it, I would of course be happy to 
contribute it back to the project. (I could write a wrapper bean, but 
this seems more fun, and since these classes have have changing field 
sets, more useful as well)

Thanks! (and thanks for Velocity!)
eric


---------------------------------------------------------------------
Eric Fixler
fix@fixler.com


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org

Re: Per-class config

[Shinobu Kawai <sh...@gmail.com>]

Hi Eric,

## Let's keep it on the list.  ;)

> OK, I think I get this.  runtime.introspector.uberspect is monolithic, 
> right?  Is there any way to specify a per-class uberspect?
Hmm.  I guess you could make a StrategyUberspect (or something like that),
and call the appropriate Uberspect according to obj.getClass().

Best regards,
-- Shinobu Kawai

--
Shinobu Kawai <sh...@gmail.com>


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org

Re: Adapting Beanlike Non-Beans for use with Velocity

[Shinobu Kawai <sh...@gmail.com>]

Hi Eric,

> 3) When should I declare a VelPropertyGet not cacheable?
I'm just guessing, but maybe when you don't want to reuse the same
VelPropertyGet when you are processing the same template again. 
ASTIdentifier#execute is where it's being cached.

> 4) Different properties in my target class are accessed via different 
> chains of method calls.  Thus far, my custom getPropertyGet instantiate 
> one type of VelPropertyGet, whose invoke() runs a conditional on the 
> property name to return the right value.
> 
> Would it be better to check the property name inside getPropertyGet and 
> write more VelPropertyGet classes, returning a VelPropertyGet 
> customized for a particular chain of method calls.
> 
> [another way of phrasing this might be 'does Velocity cache the 
> VelPropertyGets on a per-class or per-property basis?
It looks like a per-identifier basis.  Again, ASTIdentifier.

## Somebody correct me on this.  I'm likely to be wrong.  B)

Best regards,
-- Shinobu Kawai

--
Shinobu Kawai <sh...@gmail.com>


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org

Re: Adapting Beanlike Non-Beans for use with Velocity

[Shinobu Kawai <sh...@gmail.com>]

Hi Eric,

> I wrote an initial implementation of of an Uberspector that delegates 
> introspection to other Uberspectors on a per-class basis, and uses the 
> egular behavior if no alternate Uberspectors are registered.  I also 
> wrote one custom Uberpector, and so far everything seems to be working 
> really well.
Great work!

> Shinobu -- thanks for the help!  I have a couple of further questions:
I'll answer the ones I know, and leave the rest for the others.  :)

> 1) What should an Iterator returned by Uberpect.getIterator() do? 
> Iterate through properties of a class?  Or is this meant to provide 
> handle Collection-like things that don't support the Collection 
> interface?
This is used by the #foreach directive.  (Is this working for
PublicFieldUberspect?  I don't think I tested it...)

> 2) Is VelPropertyGet.getMethodName() really used anywhere (I ask 
> because I can't really return a real method name vis-a-vis the object 
> that can be used to return a specific property.  I just want to make 
> sure this won't mess anything up)
It's used somewhere in the exception handling process.  Logging
something like "the method <so-and-so> screwed up!".

> thanks again...hope the code is useful to someone.
At least it is to you.  ;)

Best regards,
-- Shinobu Kawai

--
Shinobu Kawai <sh...@gmail.com>


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org

Re: Adapting Beanlike Non-Beans for use with Velocity

[Eric Fixler <fi...@fixler.com>]

I wrote an initial implementation of of an Uberspector that delegates 
introspection to other Uberspectors on a per-class basis, and uses the 
egular behavior if no alternate Uberspectors are registered.  I also 
wrote one custom Uberpector, and so far everything seems to be working 
really well.

I posted the source code to 
http://wiki.apache.org/jakarta-velocity/MultiUberspect

Shinobu -- thanks for the help!  I have a couple of further questions:

1) What should an Iterator returned by Uberpect.getIterator() do? 
Iterate through properties of a class?  Or is this meant to provide 
handle Collection-like things that don't support the Collection 
interface?

2) Is VelPropertyGet.getMethodName() really used anywhere (I ask 
because I can't really return a real method name vis-a-vis the object 
that can be used to return a specific property.  I just want to make 
sure this won't mess anything up)

3) When should I declare a VelPropertyGet not cacheable?

4) Different properties in my target class are accessed via different 
chains of method calls.  Thus far, my custom getPropertyGet instantiate 
one type of VelPropertyGet, whose invoke() runs a conditional on the 
property name to return the right value.

Would it be better to check the property name inside getPropertyGet and 
write more VelPropertyGet classes, returning a VelPropertyGet 
customized for a particular chain of method calls.

[another way of phrasing this might be 'does Velocity cache the 
VelPropertyGets on a per-class or per-property basis?

thanks again...hope the code is useful to someone.
eric


---------------------------------------------------------------------
Eric Fixler
fix@fixler.com


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org

Re: Adapting Beanlike Non-Beans for use with Velocity

[Shinobu Kawai <sh...@gmail.com>]

Hi Eric,

> Roughly speaking, instead of using the setXxx and getXxx pattern, these 
> packages use calls like document.getField("xxx") and 
> document.setField("xxx",value).

## snip

> Any pointers greatly appreciated.  If this doesn't exist, seems useful 
> to other people, and I manage to do it, I would of course be happy to 
> contribute it back to the project. (I could write a wrapper bean, but 
> this seems more fun, and since these classes have have changing field 
> sets, more useful as well)

Here's an Uberspect implementation for public field access.
    http://wiki.apache.org/jakarta-velocity/PublicFieldUberspect
## Written by, the one and only.  ;)

The implementation of #getPropertyGet() and #getPropertySet() should
give you clues to what you want to do.  And when you get it done, the
wiki page is a great place to contribute it to.

Best regards,
-- Shinobu Kawai

--
Shinobu Kawai <sh...@gmail.com>


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org

Re: Adapting Beanlike Non-Beans for use with Velocity

[Konstantin Priblouda <kp...@yahoo.com>]

--- Eric Fixler <fi...@fixler.com> wrote:


> Roughly speaking, instead of using the setXxx and
> getXxx pattern, these 
> packages use calls like document.getField("xxx") and
> 
> document.setField("xxx",value).
> 
> I'm wondering if the bean introspection layer of
> Velocity has any 
> mechanism whereby I could write an adapter class,
> with the ultimate 
> goal being the use of these classes (or Maps, for
> that matter) just 
> like regular old Java Beans in Velocity template,
> i.e. the adapter 
> class would generate the mapping so that
> $object.property would call 
> document.getField("xxx") instead of document.getXxx.

AFAIR you can plug in your custom introspector in
velocity.  It's all in the docs. 

regards,

=====
----[ Konstantin Pribluda ( ko5tik ) ]----------------
Plugins for xdoclet-2 are releassed. check it out
http://www.sourceforge.net/projects/xdoclet-plugins/
----[ http://www.pribluda.de ]------------------------

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org