> Hopefully that's the sort of stuff you're interested in hearing about.
Yes, thanks! By "custom interceptors" I meant strategies like Open Session In View, which can be used to implement One Transaction Per Request * http://struts.apache.org/2.0.11/docs/non-ioc-version-of-opensessioninviewinterceptor.html * http://struts.apache.org/2.x/docs/hibernateandspringenabledexecuteandwaitinterceptor.html * http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/hibernate3/HibernateInterceptor.html * http://struts.apache.org/2.x/docs/adminapp.html I've seen various other references on the list to people using custom interceptors to help with data access. > We do find that doing the params/prepare/params interceptor sandwich is > a fairly elegant way to hydrate from a form-provided ID and then let > other fields inject into that newly hyrdated object on the second params > pass. Yes, that does work well. The type converters can be used to do the same sort of thing. For example, to hydrate (and dehydrate) a entity based on a primary key, we can do something like this public Object convertFromString(Map context, String[] values, Class toClass) { ProtocolManagerInterface manager = new ProtocolManager(); String id = values[0]; Protocol target = manager.find(id); return target; } public String convertToString(Map context, Object o) { Protocol value = (Protocol) o; String id = value.getId(); return id; } This tells the framework to write out the primary key when the Protocol object is referenced in a JSP, and then, on the way back, to lookup the Protocol object using the key. If an Action has a reference to, say, a User object, we can do things like <s:hidden name="user"/> <s:textfield key="user.fullName"/> <s:textfield key="user.fromAddress"/> In which case, the framework will first hydrate the user object (the string ID will be written out at the hidden field), and then update the user's properties. Of course, if the user field were left out, the framework will simply create a blank user object (automatic lazy instantiation). Elegant indeed :) -Ted. On Nov 17, 2007 1:00 AM, Gary Affonso <[EMAIL PROTECTED]> wrote: > Ted Husted wrote: > > I know the JPA is growing in popularlity among Struts developers. I > > was wondering if there are certain Struts 2 features that people where > > finding useful in using JPA or Hibernate 3 > > For us it's Hibernate 3 still. We'll be moving to JPA in the code (with > Hibernate as the underlying implementation) soon. > > > with Struts 2. Are you > > using custom interceptors? > > Er, why? > > Or, more specifically, yah we have some customer interceptors, they > don't have anything to do with our persistence layer, though. > > We are using Spring's OSIV filter if that's of interest to you. > > >, type converters? > > Nothing related to persistence. > > > Spring? > > Absolutely, and heavily. Spring for DI, DAO layer, service layer, > integration testing, Spring AOP for the fault barrier (advice on the > execute method of the Actions) and various Spring "utilities" like the > scheduling integration. > > > model-driven? > > I don't find the "formal" model driven stuff in S2 to be of much benefit > ("formal" meaning the interceptor combined with a getModel method > implementation in the Actions). > > But we do a lot of direct-injection into model objects from the view > layer simply using OGNL expressions for our field names and ensuring the > model-object is a property of the action with getters/setters. Most of > the model objects we inject into (from forms in the view) are persisted. > > We do find that doing the params/prepare/params interceptor sandwich is > a fairly elegant way to hydrate from a form-provided ID and then let > other fields inject into that newly hyrdated object on the second params > pass. > > > the scope plugin? > > Not quite yet. But very soon. > > I've been seriously playing with WebFlow and will probably use *some* > sort of framework-provided scoping very soon (WebFlow or the scope > plug-in). I'm soooo tired of managing conversation scopes by hand. > > --- > > > Hopefully that's the sort of stuff you're interested in hearing about. > > - Gary > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted <http://www.husted.com/ted/blog/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
