Confusement over the pre-population best practice

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Confusement over the pre-population best practice

Stan Broné
Hi,

The past couple of weeks I've been trying to learn Stripes, and I have  
to say I really like what I'm seeing so far. I bought the book and  
used the website, they're both great resources and I have the feeling  
I am slowly getting up to speed with the basics. However, there is  
some information on the website that makes me scratch my head.

I looked at the best practices page and the suggestion “Use @Before  
methods to pre-populate domain objects” confuses me. The description  
that's underneath it, doesn't really help me either. It says:
“When creating screens to edit existing persistent objects it's nice  
to be able to avoid copying all the properties from the nested domain  
object to the persistent one that you just looked up from the  
database. If you pre-populate the object from the database, Stripes  
will just bind the values from the request like normal, leaving you  
with an updated object ready to save.”

Is this best practice necessary for things to work smoothly? I have an  
ActionBean with a form, a domain object, and a Converter that loads  
the domain object from a DAO when its ID is given as a parameter. From  
my understanding, when I pass along the object ID in a hidden field,  
the object gets bound again on the next request and filled with the  
values that were entered in  my form. What am I missing? - Or am I  
going wrong here in assuming that is the order in which things happen?

At first glance I don't see how the hydration scheme is an  
improvement. It's called before the binding and validation process  
takes place, which means that it happens before the automatic  
parameter binding (right?). If I read correctly this means that I have  
to hydrate the object by myself by using a request parameter and  
querying my DAO object. So I am basically doing work that Stripes can  
handle on its own, and I am not even getting the advantage of  
automatic type conversion.

Before looking into this I was using a “lazy getter” approach for  
getting my data from the database. I can see that the best practise  
makes my code a bit leaner because the getters and setters contain  
less code. It also makes StrictBinding a bit easier because there's  
one less parameter to bind. But surely, that can't be all there is to  
it?

It's probably one of these things that you have to get your head  
around but I'm not seeing it yet. I would really appreciate the  
insight of someone who knows more about this.

Thanks.

Stan

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusement over the pre-population best practice

Iwao AVE!
Hi Stan,

You seem to understand the binding process correctly.
The TypeConverter approach should work as good as the @Before method approach.
It might not worth creating a TypeConverter class when it is used only
in one ActionBean.

Hope this helps,
Iwao

2013/12/29 Stan Broné <[hidden email]>:

> Hi,
>
> The past couple of weeks I've been trying to learn Stripes, and I have
> to say I really like what I'm seeing so far. I bought the book and
> used the website, they're both great resources and I have the feeling
> I am slowly getting up to speed with the basics. However, there is
> some information on the website that makes me scratch my head.
>
> I looked at the best practices page and the suggestion “Use @Before
> methods to pre-populate domain objects” confuses me. The description
> that's underneath it, doesn't really help me either. It says:
> “When creating screens to edit existing persistent objects it's nice
> to be able to avoid copying all the properties from the nested domain
> object to the persistent one that you just looked up from the
> database. If you pre-populate the object from the database, Stripes
> will just bind the values from the request like normal, leaving you
> with an updated object ready to save.”
>
> Is this best practice necessary for things to work smoothly? I have an
> ActionBean with a form, a domain object, and a Converter that loads
> the domain object from a DAO when its ID is given as a parameter. From
> my understanding, when I pass along the object ID in a hidden field,
> the object gets bound again on the next request and filled with the
> values that were entered in  my form. What am I missing? - Or am I
> going wrong here in assuming that is the order in which things happen?
>
> At first glance I don't see how the hydration scheme is an
> improvement. It's called before the binding and validation process
> takes place, which means that it happens before the automatic
> parameter binding (right?). If I read correctly this means that I have
> to hydrate the object by myself by using a request parameter and
> querying my DAO object. So I am basically doing work that Stripes can
> handle on its own, and I am not even getting the advantage of
> automatic type conversion.
>
> Before looking into this I was using a “lazy getter” approach for
> getting my data from the database. I can see that the best practise
> makes my code a bit leaner because the getters and setters contain
> less code. It also makes StrictBinding a bit easier because there's
> one less parameter to bind. But surely, that can't be all there is to
> it?
>
> It's probably one of these things that you have to get your head
> around but I'm not seeing it yet. I would really appreciate the
> insight of someone who knows more about this.
>
> Thanks.
>
> Stan
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users