Menu
▾
▴
Re: [Springframework-developer] Fw: Spring and OGNL
|
From: Mike Cannon-B. <mi...@at...> - 2004-02-11 23:54:34
|
Yes, this would be awesome and most appreciated! (see my previous post to the list a few months ago) M On 12/2/04 10:27 AM, "Rod Johnson" (rod...@in...) penned the words: > 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 \ >> +---------------------------------+ >> >> >> > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
