You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Mike Williams <mi...@cortexebusiness.com.au> on 2001/10/03 03:04:13 UTC
wrapping XML document as JavaBeans?
Say I have the following XML document:
<bean>
<name>UserInfo</name>
<field>
<name>id</name>
<type>int</type>
</field>
<field>
<name>name</name>
<type>java.lang.String</type>
</field>
</bean>
I want to make the data therein available to a Velocity template. I could
do what Anakia does, and simply place a JDOM representation in the
Context. However, then I'd end up with template expressions like
$field.getChild("name").getText()
when I'd much rather write:
$field.name
I could create explicit model JavaBean objects, like Torque does, but I
might want to deal with lots of different XML documents, and don't want to
have to generate a set of JavaBeans for each DTD.
Are there any other options? Would it be feasible to create a generic
wrapper-ojbect that allows <field><name>id</name></field> to be accessed as
"$field.name" ?
--
cheers, Mike
Re: wrapping XML document as JavaBeans?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 10/3/01 6:59 AM, "Attila Szegedi" <sz...@freemail.hu> wrote:
> AFAIK, Tea is not constrained. It will happily allow you to call any
> accessible method on any object introduced to the template.
Hm. Ok - I thought it was constrained to a subset of the beanspec. I
haven't used it, though, so I am not sure...
>
> Attila.
>
>
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> To: <ve...@jakarta.apache.org>
> Sent: 2001. október 3. 12:30
> Subject: Re: wrapping XML document as JavaBeans?
>
>
> <snip/>
>
> From what I understand, Tea is also constrained in what you can access.
>
> geir
--
Geir Magnusson Jr. geirm@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
Re: wrapping XML document as JavaBeans?
Posted by Attila Szegedi <sz...@freemail.hu>.
AFAIK, Tea is not constrained. It will happily allow you to call any accessible method on any object introduced to the template.
Attila.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: <ve...@jakarta.apache.org>
Sent: 2001. október 3. 12:30
Subject: Re: wrapping XML document as JavaBeans?
<snip/>
>From what I understand, Tea is also constrained in what you can access.
geir
--
Geir Magnusson Jr. geirm@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
Re: wrapping XML document as JavaBeans?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 10/3/01 6:20 AM, "Attila Szegedi" <sz...@freemail.hu> wrote:
>
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> To: <ve...@jakarta.apache.org>
> 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
> "field.name"), 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
--
Geir Magnusson Jr. geirm@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
Re: wrapping XML document as JavaBeans?
Posted by Attila Szegedi <sz...@freemail.hu>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: <ve...@jakarta.apache.org>
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 "field.name"), 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.
> geir
Attila.
Re: wrapping XML document as JavaBeans?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 10/3/01 4:29 AM, "Attila Szegedi" <sz...@freemail.hu> wrote:
> Hopefully I won't get lynched here for drawing your attention to another
> template engine, but the XML support in the Freemarker template engine uses a
> quite comfortable syntax close to what you described - your example would be
> ${field.name._text} in Freemarker. If you want to evaluate it, go to
> http://freemarker.sourceforge.net.
>
No lynching :) That's neat - I am curious about what 'holds' the XML. Will
go look...
geir
> Attila.
>
> ----- Original Message -----
> From: "Mike Williams" <mi...@cortexebusiness.com.au>
> To: <ve...@jakarta.apache.org>
> Sent: 2001. október 3. 3:04
> Subject: wrapping XML document as JavaBeans?
>
>
>> Say I have the following XML document:
>>
>> <bean>
>> <name>UserInfo</name>
>> <field>
>> <name>id</name>
>> <type>int</type>
>> </field>
>> <field>
>> <name>name</name>
>> <type>java.lang.String</type>
>> </field>
>> </bean>
>>
>> I want to make the data therein available to a Velocity template. I could
>> do what Anakia does, and simply place a JDOM representation in the
>> Context. However, then I'd end up with template expressions like
>>
>> $field.getChild("name").getText()
>>
>> when I'd much rather write:
>>
>> $field.name
>>
>> I could create explicit model JavaBean objects, like Torque does, but I
>> might want to deal with lots of different XML documents, and don't want to
>> have to generate a set of JavaBeans for each DTD.
>>
>> Are there any other options? Would it be feasible to create a generic
>> wrapper-ojbect that allows <field><name>id</name></field> to be accessed as
>> "$field.name" ?
>>
>> --
>> cheers, Mike
>>
>>
>
--
Geir Magnusson Jr. geirm@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
Re: wrapping XML document as JavaBeans?
Posted by Attila Szegedi <sz...@freemail.hu>.
Hopefully I won't get lynched here for drawing your attention to another template engine, but the XML support in the Freemarker template engine uses a quite comfortable syntax close to what you described - your example would be ${field.name._text} in Freemarker. If you want to evaluate it, go to http://freemarker.sourceforge.net.
Attila.
----- Original Message -----
From: "Mike Williams" <mi...@cortexebusiness.com.au>
To: <ve...@jakarta.apache.org>
Sent: 2001. október 3. 3:04
Subject: wrapping XML document as JavaBeans?
> Say I have the following XML document:
>
> <bean>
> <name>UserInfo</name>
> <field>
> <name>id</name>
> <type>int</type>
> </field>
> <field>
> <name>name</name>
> <type>java.lang.String</type>
> </field>
> </bean>
>
> I want to make the data therein available to a Velocity template. I could
> do what Anakia does, and simply place a JDOM representation in the
> Context. However, then I'd end up with template expressions like
>
> $field.getChild("name").getText()
>
> when I'd much rather write:
>
> $field.name
>
> I could create explicit model JavaBean objects, like Torque does, but I
> might want to deal with lots of different XML documents, and don't want to
> have to generate a set of JavaBeans for each DTD.
>
> Are there any other options? Would it be feasible to create a generic
> wrapper-ojbect that allows <field><name>id</name></field> to be accessed as
> "$field.name" ?
>
> --
> cheers, Mike
>
>
Re: wrapping XML document as JavaBeans?
Posted by Dan Bachelder <ch...@chowda.net>.
I hate to go off topic again... but speaking of hashmap... here is a very
interesting article on hashmaps and performance... with some numbers on page
2...
http://www.onjava.com/pub/a/onjava/2001/01/25/hash_functions.html
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: <ve...@jakarta.apache.org>
Sent: Tuesday, October 02, 2001 9:59 PM
Subject: Re: wrapping XML document as JavaBeans?
> On 10/2/01 9:43 PM, "David Rees" <dr...@runt.ebetinc.com> wrote:
> >>
> >> You might also choose to build something path-ish so you can access any
> >> level...
> >
> > Yep, you could easily do this using a HashMap so you don't have to write
a
> > custom container, just something to parse/store it:
> >
> > <object>
> > <value>Data</value>
> > <some>
> > <othervalue>MoreData</othervalue>
> > </some>
> > </object>
> >
> > object.get("value")
> > object.get("some/othervalue")
> >
> > If you have elements with attributes with the same name as lower
elements,
> > things could get tricky, but that's a pooly designed XML spec anyway.
;-)
>
> I did this for JJAR. I will pull that code out and see if I can package
it
> up....
>
> It used lists and maps... Pretty cheap and simple..
>
>
> --
> Geir Magnusson Jr. geirm@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
>
>
>
Re: wrapping XML document as JavaBeans?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 10/2/01 9:43 PM, "David Rees" <dr...@runt.ebetinc.com> wrote:
>>
>> You might also choose to build something path-ish so you can access any
>> level...
>
> Yep, you could easily do this using a HashMap so you don't have to write a
> custom container, just something to parse/store it:
>
> <object>
> <value>Data</value>
> <some>
> <othervalue>MoreData</othervalue>
> </some>
> </object>
>
> object.get("value")
> object.get("some/othervalue")
>
> If you have elements with attributes with the same name as lower elements,
> things could get tricky, but that's a pooly designed XML spec anyway. ;-)
I did this for JJAR. I will pull that code out and see if I can package it
up....
It used lists and maps... Pretty cheap and simple..
--
Geir Magnusson Jr. geirm@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
Re: wrapping XML document as JavaBeans?
Posted by David Rees <dr...@runt.ebetinc.com>.
On Tue, Oct 02, 2001 at 09:12:35PM -0400, Geir Magnusson Jr. wrote:
> >
> > when I'd much rather write:
> >
> > $field.name
> >
> > I could create explicit model JavaBean objects, like Torque does, but I
> > might want to deal with lots of different XML documents, and don't want to
> > have to generate a set of JavaBeans for each DTD.
> >
> > Are there any other options? Would it be feasible to create a generic
> > wrapper-ojbect that allows <field><name>id</name></field> to be accessed as
> > "$field.name" ?
>
> Sure - I would think that's pretty easy if you want simple access.
>
> For example, implement on your wrapper-object
>
> Public Object get(String)
>
> And return the child node (in the same object class).
>
> $field.name will make velocity call get("name")
>
> You might also choose to build something path-ish so you can access any
> level...
Yep, you could easily do this using a HashMap so you don't have to write a
custom container, just something to parse/store it:
<object>
<value>Data</value>
<some>
<othervalue>MoreData</othervalue>
</some>
</object>
object.get("value")
object.get("some/othervalue")
If you have elements with attributes with the same name as lower elements,
things could get tricky, but that's a pooly designed XML spec anyway. ;-)
-Dave
Re: wrapping XML document as JavaBeans?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 10/2/01 9:04 PM, "Mike Williams" <mi...@cortexebusiness.com.au> wrote:
> Say I have the following XML document:
>
> <bean>
> <name>UserInfo</name>
> <field>
> <name>id</name>
> <type>int</type>
> </field>
> <field>
> <name>name</name>
> <type>java.lang.String</type>
> </field>
> </bean>
>
> I want to make the data therein available to a Velocity template. I could
> do what Anakia does, and simply place a JDOM representation in the
> Context. However, then I'd end up with template expressions like
>
> $field.getChild("name").getText()
>
> when I'd much rather write:
>
> $field.name
>
> I could create explicit model JavaBean objects, like Torque does, but I
> might want to deal with lots of different XML documents, and don't want to
> have to generate a set of JavaBeans for each DTD.
>
> Are there any other options? Would it be feasible to create a generic
> wrapper-ojbect that allows <field><name>id</name></field> to be accessed as
> "$field.name" ?
I just upladed to /whiteboard/geir a jar xmleb.jar that contains an
example/starter of a tool like this.
It's pretty simple, but lets to take XML like
<?xml version="1.0" ?>
<!DOCTYPE document >
<document>
<email>geirm@apache.org</email>
<people>
<person gender="male">
<name>geir</name>
<height>6'1"</height>
</person>
<person gender="female">
<name>garbis</name>
<height>7"</height>
</person>
</people>
</document>
( Garbis is my cat... She believes she is a person.)
And access in a template like
Email : $xml.email
#foreach($person in $xml.people.person)
Name = $person.name ($person.getAttribute('gender') )
$person.height
#end
For output like
Email : geirm@apache.org
Name = geir (male )
6'1"
Name = garbis (female )
7"
There are a whole bunch of things I don't really like about it, but figured
I would toss out here to see what happens...
If we like it, we can put in the contrib section.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
AW: wrapping XML document as JavaBeans?
Posted by Israel Strobel <st...@egadgets.de>.
Well I'm actually using Velocity for XML Transformation, rather then using
XSLT. Therefore I have a tool which converts an XML Document, to a DOM
Object and then builds an Hashtable tree out of the DOM Object. So you can
simply write:
$person.address.country
Then I use an empty XML Document as template, and fill it up with Velocity.
I can give you the code if you're interessted.
Greets,
Israel Strobel
> -----Ursprungliche Nachricht-----
> Von: mikew@byrd.int.cortexebusiness.com.au
> [mailto:mikew@byrd.int.cortexebusiness.com.au]Im Auftrag von Mike
> Williams
> Gesendet: Mittwoch, 3. Oktober 2001 03:04
> An: velocity-user@jakarta.apache.org
> Betreff: wrapping XML document as JavaBeans?
>
>
> Say I have the following XML document:
>
> <bean>
> <name>UserInfo</name>
> <field>
> <name>id</name>
> <type>int</type>
> </field>
> <field>
> <name>name</name>
> <type>java.lang.String</type>
> </field>
> </bean>
>
> I want to make the data therein available to a Velocity template. I could
> do what Anakia does, and simply place a JDOM representation in the
> Context. However, then I'd end up with template expressions like
>
> $field.getChild("name").getText()
>
> when I'd much rather write:
>
> $field.name
>...
Re: wrapping XML document as JavaBeans?
Posted by Brian Lloyd-Newberry <ne...@yahoo.com>.
--- Jon Stevens <jo...@latchkey.com> wrote:
> Most people populate data objects from an XML file or RDBMS.
I played with XML here a little but wanted the $obj.attr interface not
the one that I was seeing with navigating XML trees and all. There is
no RDBMS access in the system since we are using an in-memory data
model that is not locally backed by a database (i.e. distributed
system). I also made the decision early on that we were going to
sepertate presentation data from business data (not unlike presentation
logic from business logic) and the velocity solution made things clean
and allowed me to "merge" the two data forms at presentation time. I
would have prefered XML but ran out of time and Velocity was already
there, so... :)
> This is exactly what Torque is for.
I understood torque was for "automagicing" the RDBMS <--> Object
interface. I may be misunderstanding my reading of the info on the
Turbine site. Since we had the requirement of having designers being
able to work on a static data set without access to the RDBMS (or in
our case the in-memory data model) this would be a problem. :)
> But, whatever floats your boat. If it makes you happy...
Actually in this case it was "Whatever keeps your boat floating." :)
Thanks for the feedback. And keep up the good work!
-Brian
__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com
Re: wrapping XML document as JavaBeans?
Posted by Jon Stevens <jo...@latchkey.com>.
on 10/3/01 8:52 AM, "Brian Lloyd-Newberry" <ne...@yahoo.com> wrote:
> Some of you ( probably Jon ;P ) are probably wondering what I am
> using this for. The beauty of this is that I can write up some
> "velocity" data files that represent the data model that we will be
> using for an application and provide a very simple servlet to load them
> into the context to render against display templates. This allows
> developers to be working on layout at the same time I am working on the
> servlet <--> data interface with strong business rules. I also can
> seperate "presentation" data for objects out into these seperate files
> and merge it with data from the result set which has been piped into a
> collection of "metaobjects". I have also used this toolkit to implement
> a code generator for our business objects.
Most people populate data objects from an XML file or RDBMS.
This is exactly what Torque is for.
But, whatever floats your boat. If it makes you happy...
-jon
Re: wrapping XML document as JavaBeans?
Posted by Brian Lloyd-Newberry <ne...@yahoo.com>.
--- Mike Williams <mi...@cortexebusiness.com.au> wrote:
> Say I have the following XML document:
>
> <bean>
> <name>UserInfo</name>
> <field>
> <name>id</name>
> <type>int</type>
> </field>
> <field>
> <name>name</name>
> <type>java.lang.String</type>
> </field>
> </bean>
>
> I want to make the data therein available to a Velocity template. I
> could
> do what Anakia does, and simply place a JDOM representation in the
> Context. However, then I'd end up with template expressions like
>
> $field.getChild("name").getText()
>
> when I'd much rather write:
>
> $field.name
>
> I could create explicit model JavaBean objects, like Torque does, but
> I
> might want to deal with lots of different XML documents, and don't
> want to
> have to generate a set of JavaBeans for each DTD.
>
> Are there any other options? Would it be feasible to create a
> generic
> wrapper-ojbect that allows <field><name>id</name></field> to be
> accessed as
> "$field.name" ?
>
I have some code that I have promised to "donate" to the project as
soon as I get some time to work on cleaning and documenting it that
does something similar in a non-XML way. I would love to "integrate"
some kind of XML solution with it but havn't had time (the one thing we
are all lacking ;}).
The basic premise is an object that wraps a hash table. It enforces
that keys can only be strings. So you can (in velocity) do something
like:
$bean = $UTILS.METAOBJ.newObject( "Widget" )
$bean.set( 'id', $UTILS.NUMBER.asInteger(5) )
$bean.set( 'name', 'blue widget' )
$beancollection = $UTILS.METAOBJ.newCollection()
$beancollection.add( $bean )
$bean = $UTILS.METAOBJ.newObject( "Widget" )
$bean.set( 'id', $UTILS.NUMBER.asInteger(10) )
$bean.set( 'name', 'green widget' )
I can then do a:
#foreach( $bean in $beancollection )
Bean "$bean.name" has an id of $bean.id
#end
An XML version of this would certainly be possible. I might even
play with whipping up a version that would "compile" some XML schema
into the format seen above. The benefit to that would be that I could
use the schema validator to validate the XML data format in a much more
"strict" way than writing a bunch of velocity code.
Some of you ( probably Jon ;P ) are probably wondering what I am
using this for. The beauty of this is that I can write up some
"velocity" data files that represent the data model that we will be
using for an application and provide a very simple servlet to load them
into the context to render against display templates. This allows
developers to be working on layout at the same time I am working on the
servlet <--> data interface with strong business rules. I also can
seperate "presentation" data for objects out into these seperate files
and merge it with data from the result set which has been piped into a
collection of "metaobjects". I have also used this toolkit to implement
a code generator for our business objects.
In hindsight I think I may have done things a little differently but
as the only developer on the project I needed a way to "enable" others
without programming skills to help themselves easily.
It looks like it will be pretty hectic here until the end of October
but I will try to squeeze in some cleanup and documentation before
then. We will see. Then I need to figure out how to "contribute" it
since it really is not a part of velocity but a tool to be used with
it. (If people even are interested).
On a seperate note, I can't express how Awsome all of the "core"
developers on the Velocity project are. They have put together a tool
that has saved me hundereds of hours and will continue to do so for as
far as I can see down the road. I wish to say again, Thanks a million!
-Brian
=====
Brian S. Lloyd-Newberry
Vertical Learning Curve Solutions
newbeb@yahoo.com
__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com
Re: wrapping XML document as JavaBeans?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 10/2/01 9:04 PM, "Mike Williams" <mi...@cortexebusiness.com.au> wrote:
> Say I have the following XML document:
>
> <bean>
> <name>UserInfo</name>
> <field>
> <name>id</name>
> <type>int</type>
> </field>
> <field>
> <name>name</name>
> <type>java.lang.String</type>
> </field>
> </bean>
>
> I want to make the data therein available to a Velocity template. I could
> do what Anakia does, and simply place a JDOM representation in the
> Context. However, then I'd end up with template expressions like
>
> $field.getChild("name").getText()
>
> when I'd much rather write:
>
> $field.name
>
> I could create explicit model JavaBean objects, like Torque does, but I
> might want to deal with lots of different XML documents, and don't want to
> have to generate a set of JavaBeans for each DTD.
>
> Are there any other options? Would it be feasible to create a generic
> wrapper-ojbect that allows <field><name>id</name></field> to be accessed as
> "$field.name" ?
Sure - I would think that's pretty easy if you want simple access.
For example, implement on your wrapper-object
Public Object get(String)
And return the child node (in the same object class).
$field.name will make velocity call get("name")
You might also choose to build something path-ish so you can access any
level...
geir
--
Geir Magnusson Jr. geirm@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