ModelDriven - Best Practices

["CRANFORD, CHRIS" <Ch...@setech.com>]

I recently implemented an action using the ModelDriven interface.  Since
my Domain Object doesn't contain anything beyond properties that are
mapped to columns in the associated table; it made it easy to pass the
data between the DAO, Service, and View tiers.

o Creation

During creation, everything seemed to work very well.  The prepare()
call instantiated a new domain object, the JSP properties passed were
set in the domain object and then the service set the remaining values
that it handles when a record gets initially created.  

o Read

During the read operation, the domain object is simply passed by the
service back to the view, the JSP renders the record data; no problem.

o Update

This is where I initially noticed a problem with the ModelDriven
interface.  When an update comes in, if the JSP submits a subset of the
values on the model, fields which are not set by the submit are set back
to null.  Only fields which were in the POST from the form were
initialized.

I would have expected my prepare() to query the database record during
the submission process, the interceptor would have only set the
submitted field values to their new values and left the existing fields
unchanged and consistent with the database; but it didn't.

Is the only alternative to accept what the ModelDriven object gets set
with and then in my service's "update" method to pick and choose what
fields from the submitted model to change in my entity before I commit
it?

o Delete 

No problems where.  Simply the record id is submitted, the record
queried, and then the service executes a delete based on the ID value.


Any thoughts on my update issue?
Chris



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: ModelDriven - Best Practices

[Paweł Wielgus <po...@gmail.com>]

Hi Chris,
are You using paramPrepareParams stack?
It should work with it like You expect it to.

Best greetings,
Paweł Wielgus.


2011/1/24 CRANFORD, CHRIS <Ch...@setech.com>:
> I recently implemented an action using the ModelDriven interface.  Since
> my Domain Object doesn't contain anything beyond properties that are
> mapped to columns in the associated table; it made it easy to pass the
> data between the DAO, Service, and View tiers.
>
> o Creation
>
> During creation, everything seemed to work very well.  The prepare()
> call instantiated a new domain object, the JSP properties passed were
> set in the domain object and then the service set the remaining values
> that it handles when a record gets initially created.
>
> o Read
>
> During the read operation, the domain object is simply passed by the
> service back to the view, the JSP renders the record data; no problem.
>
> o Update
>
> This is where I initially noticed a problem with the ModelDriven
> interface.  When an update comes in, if the JSP submits a subset of the
> values on the model, fields which are not set by the submit are set back
> to null.  Only fields which were in the POST from the form were
> initialized.
>
> I would have expected my prepare() to query the database record during
> the submission process, the interceptor would have only set the
> submitted field values to their new values and left the existing fields
> unchanged and consistent with the database; but it didn't.
>
> Is the only alternative to accept what the ModelDriven object gets set
> with and then in my service's "update" method to pick and choose what
> fields from the submitted model to change in my entity before I commit
> it?
>
> o Delete
>
> No problems where.  Simply the record id is submitted, the record
> queried, and then the service executes a delete based on the ID value.
>
>
> Any thoughts on my update issue?
> Chris
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org