[offline conversation returned to thread]
Igor,
I understand about using the AccountBean. That is not where the problem
lies.
Problem: how to update encapsulated field(s) of the Account object from the
AccountBean??? See details below. Account does NOT have set methods for
these fields, so I cannot simply copy properties from the bean to the
newly-created object. That is the difficulty.
Thanks,
RDC
i dont see why you have to give up encapsulation of anything...
the bean you create does not extend account, in fact it extends
nothing, just implements serializable. you only need this bean when
you are creating a new instance of account.
then in onsubmit() you do
onsubmit() {
AccountBean bean=getModelObject();
Account acc=new Account(bean.getEmail());
// copy other properties from bean to acc
dao.save(acc);
// ^ at this point you should have the id set by hibernate
setModel(new HibernateEntityModel(acc));
// ^ notice we set a new model, from now on this form will operate
on the instance of Account object
}
-igor
On Jan 24, 2008 6:42 PM, RDC <[EMAIL PROTECTED]> wrote:
> Igor,
>
> Thanks again for your time.
>
> Here's the difficulty I am having with implementing the bean idea.
>
> Account is a subclass of another class, let's call it Persistable.
> Persistable has a
private rowId field which represents the id of the object in a relational
db. That class
implements a public getRowId() method, but NOT a setRowId method. This is
the design
recommended by Hiberate, which I am using as my ORM. Hibernates sets the
rowId field
directly reflexively, using a value provided by the db.
>
> Let's say the Form has an AccountBean as its model object. That bean gets
> updated by
the FormComponents without problem. It also gets saved to the db, and
Hibernate sets its
rowId field. So far, so good.
>
> The problem: how to set the rowId of the newly-created Account object from
> the
AccountBean, while at the same time keeping respecting the encapsulation of
rowId????
Only two choices I see are:
>
> 1. create a protected setRowID() method in Persistable (Persistable and
> Account are
in different packages); or
> 2. set the rowId field reflexively.
>
> As in all good software engineering, both have pluses and minuses and
> involve
tradeoffs. I am really hesitant to give up the safety of the strong
encapsulation of the
rowId field. Plus, there are other fields with similar limitation. This
prompted me to
try to find a different solution.
>
> Would love your thoughts on this. Like everyone, my knowledge of java is
> incomplete.
Do you see any other options?
>
> RDC
> > Although I believe your solution is the best because of its simplicity,
> due to
other (non-wicket) constraints in my design (encapsulation of fields of an
Account
superclass), I was unable to use a bean or subclass the form.
>
> not really sure why this is an issue for you. give
> class Account { private String email,name; public Account(String
> email) { ... } ... }
>
> you can always do
>
> class AccountBean { private String email,name;}
>
> set instance of AccountBean as the model object of the form and then
> in onsubmit() { AccountBean bean=getModelObject(); Account account=new
> Account(bean.getEmail()); account.setName(bean.getName());
> form.setModelObject(account); }
>
> you dont break any encapsulation...
>
>
> cheers,
> -igor
and it is also more elegant to e.g. create a copy constructor or
utility object for copying so that you don't have your submit method
littered with code to copy properties. That's largely a matter of
taste though.
--
View this message in context:
http://www.nabble.com/create-new-model-object-of-a-Form-from-one-of-its-FormComp-values---tp14983110p15098864.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
