Koen Jans a écrit :

>Here's my problem;
>
>A user has several accounts, represented by AccountBean objects, all
>having a unique accountId. 
>
>Now, i have a form where the user can select one of his accounts to edit
>through a radio button selection. For the associated ActionForm, i see
>two options to represent the selected account;
>
>1) on my ActionForm;  a property "int selectedAccountId"
>2) on my ActionForm;  a property "AccountBean selectedAccount" 
>
>The first option seems good because it preserves the philosophy that an
>ActionForm represents the user's input..
>
>The second is nice because the edit-Action, associated with the form,
>can immediately extract the selectedAccount from the ActionForm, whereas
>using the first approach, a database call is needed to retrieve the
>selected account again by the account's id.
>
>Which option would you prefer, and especially why? Thanks for your time
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>  
>
The second option may have some problems imho. Every setter in AccountBean
is potentially accessible from the user's point of view using
http://host/webapp/accountAction.do?XXX=12345 where there is a setXXX() on
bean. If your bean is just there to represent some informations (that is
every call
to setXXX is legitimate for user having rights to the .do action)
there is no problem with it. But if your bean is, for example, to be
persisted as is in a database,
this might be dangerous. What happen if a clerk presented an
editAccountPersonalInformations
from does use this immediate access to call via struts setAccountCredit() ?

Now, i have used your second option quite often, on places where i
didn't mind
access rights.

Now a good way to prevent illegal access to methods is to use the
AccountBean private inside form
and provide public delegate call to legitimate methods :)

regards


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to