Thread: [Springframework-developer] Fw: Spring and OGNL

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Drew,

Thanks for your email. OGNL support is on our todo list and has come up on
the developer list. The scope of Spring 1.0 is finalized now, but this could
well be worthwhile for Spring 1.1.

I hope you don't mind--I've forwarded your email to the developer list.

Regards,
Rod

----- Original Message -----
From: "Drew Davidson" <dr...@og...>
To: <rod...@in...>
Sent: Wednesday, February 11, 2004 5:08 PM
Subject: Spring and OGNL

> Rod,
>
> I've been reading about Spring with a lot of interest.  I like the ideas
> of decoupling configuration, etc. from the beans themselves and I
> especially like the idea of configuring POJOs through accessors.   I
> read TheServerSide article that you wrote last October with great
> interest; there is a lot of material to cover.
>
> I wanted to bring OGNL (http://www.ognl.org) to your attention because
> it has been used in these types of "glue" environments to great effect.
> Tapestry and WebWork, for example, use OGNL to bind objects in their
> component web solutions (OGNL's type conversion and dynamic nature make
> it very suitable for these applications).
>
> The most relevant use of OGNL for Spring's purposes would be in the bean
> configuration file.  I have similar configuration files in my projects,
> but I use OGNL to allow for expressions within <value>-type of
> statements.  This allows you to access static variables, instantiate
> objects which would otherwise be difficult to specify generically.
>
> For example, most of the configuration depends on specifying a class
> name and properties.  Assumptions of this are that there is a no-arg
> constructor and that the Java Bean is well-formed (i.e. JavaBeans
> properties with names, etc.).   Configuring properties appears to be
> simple property names - correct me if I'm wrong.
>
> Two extensions to this bean spec occur to me immediately:
>
>     * <property name="username">
>           The name is a simple reflective property that you could use
> JavaBeans to look up and dispatch.  I would use OGNL here to do the work
> of dispatching, which would allow you to expand the scope of what "name"
> is to an OGNL expression.  This would allow you to configure a property
> with an arbitrary path, if that object were a composite object.  Here is
> an example of a User class that has a profile attached that contains
> first and last name and an arbitrary number of street addresses.   This
> example navigates the "root" object (the configured object) to get to
> the "profile" object, then further to set properties "firstName" and
> "lastName"; it then navigates through the "addresses" list (OGNL can
> treat any list-like object with the same syntax) and puts the "primary"
> address information in.
>        <property name="firstName"
> expression="profile.firstName"><value>Drew</value></property>
>        <property name="lastName"
> expression="profile.lastName"><value>Davidson</value></property>
>        <property name="primaryAddress1"
> expression="profile.addresses[0].address1"><value>1234 Elm
> St.</value></property>
>        <property name="primaryCity"
> expression="profile.addresses[0].city"><value>Tucson</value></property>
>        <property name="primaryState"
> expression="profile.addresses[0].state"><value>AZ</value></property>
>        <property name="primaryZip"
> expression="profile.addresses[0].zip"><value>85741</value></property>
>        <property name="username"
> expression="username"><value>Drew</value></property>
>
>     * I would further expand the <value> to include possible OGNL
> expressions to allow for more robust object specification.  OGNL also
> reduces the type conversion burden by utomatically converting common
> types to other types in method calls and properties (the type conversion
> is extensible also).  The "State" example in the above might be better
> served if there were a dynamic lookup of a "State" object based on a
lookup:
>
>     <property
>
name="primaryState"><expression>@State@getState("AZ")</expression></property
>
>
> Of course <expression> would yield any valid Java object as a result;
> OGNL would handle the type conversion through the property expression
> you specify; if the value were a String and the setter for the property
> actually took and Integer (or int), OGNL would automatically convert to
> the right type.
>
> I'd love to hear your views on this.  I believe that OGNL could
> significantly enhance Spring without adding any more complexity (i.e. it
> would automatically support the existing XML formats, etc. without
change).
>
> If you want other opinions on OGNL in terms of how it can enhance a
> framework please email:
>
>        Howard Lewis Ship (creator of Tapestry): hl...@co...
>        Erik Hatcher (Ant commiter and speaker of note):
> er...@eh...
>        Patrick Lightbody (WebWork2 committer): pli...@ya...
>
> - Drew
>
> --
> +---------------------------------+
> < Drew Davidson | OGNL Technology >
> <     Professional Open Source    >
> +---------------------------------+
> |  Email: dr...@og...          /
> |    Web: http://www.ognl.org   /
> |    Vox: (520) 531-1966       <
> |    Fax: (520) 531-1965        \
> | Mobile: (520) 405-2967         \
> +---------------------------------+
>
>
>

Thread: [Springframework-developer] Fw: Spring and OGNL

springframework-developer