Object Hydration API

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Object Hydration API

Gary Moselen
Hello,

I use Stripernate to hydrate model objects that are exposed in ActionBeans.

On the Stripes wiki there is a guide to how to do this with some custom
code and a preBind method:
http://www.mc4j.org/confluence/display/stripes/Binding+Into+Domain+Models

We have another team looking at using Stripes but they might not want to
expose Hibernate model objects in the same way we do, but instead
hydrate their model objects from a service/dao layer (custom code
similar to the wiki page).

I know that this hydration problem is solved by
Stripernate/TypeConverters and the other techniques, but it does seem
like a common enough problem and worthwhile enough to perhaps have
Stripes give it some attention in it's own API and support 'hydration'
out of the box. The current solutions work well enough but they aren't
really super obvious and natural solutions for a new user to *get*. If
hydration were a first class concept in Stripes itself it could be more
robust and useful.

The scenarios for integrating Stripes are:

    1) Expose model objects in ActionBeans
    2) Use FormBeans and merge into Model in ActionBean
    3) Use FormBeans and call into entirely seperate layer that
manipulates Model objects or does JDBC  

I think scenario's 1 & 2 are really common and could benefit from making
Object hydration a first class concept in Stripes; scenario 3 can't be
helped. In the first case hydration could occur before other parameter
binding and Stripes would know about special ID parameters:

@UrlBinding("/foo.action")
class Foo implements ActionBean {

    private SomeModelObject model;

    @Hydrate(id = "model.uniqueId" on = "edit")
    public SomeModelObject getModel(){
        return model;
    }
    //...
}

POST parameters look like: model.uniqueId=1234&model.description=asdf

<init-param>
    <param-name>Hydrator.Class</param-name>
    <param-value>com.MyHydrator</param-value>
</init-param>    

A Generic Hydrator:

interface Hydrator {

    public Object hydrate(Class forType, Object id);

}

OR a type specific hydrator could be specified in @Hydrate annotation:

interface Hydrator<T,V> {

    public T hydrate(V id);

}


For scenario 2, seperate FormBeans and Model objects but you still want
to hydrate them, then the Id param can hook into the formBean ids and
hydrate that way:

class Foo implements ActionBean {

    private List<MyFormBean> formBeans;

    private List<SomeModelObject> model;

    public List<MyFormBean> getFormBeans(){
        return formBeans;
    }

    @Hydrate(id = "formBean.uniqueId" on = "edit") //hydrate based on
formBean ids
    @BindAccess(NEVER)
    public List<SomeModelObject> getModels(){
        return model;
    }
    //...
}

POST parameters look like:
formBean[0].uniqueId=1234&formBean.description=asdf
or even composite ids:
POST parameters look like:
formBean[0].uniqueId.value=1234&formBean[0].uniqueId.type=XXX

but that has the side-effect of auto hydrating your model objects (which
can't be directly bound to) and then you merge changes in manually in
the event handler.

These are just some ideas, and if the reaction is that this is
functionality that Stripes shouldn't directly address or is adequately
addressed by the existing stuff then I will just keep quiet and use
Stripernate, but otherwise anyone have any thoughts?

thanks,
Gary



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users