On Tue, 30 Apr 2002, Struts Newsgroup wrote:
> Date: Tue, 30 Apr 2002 08:55:01 -0700
> From: Struts Newsgroup <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: DynaActionForm example
>
> Subject: Re: DynaActionForm example
> From: Vic Cekvenich <[EMAIL PROTECTED]>
> ===
> It was not set up for a bite, I just talk a lot on my opinion, and
> sometimes learn when I get feedback.
>
> The FormBean lets me code in Java (vs Dynabeans XML). It lets me format,
> validate, convert, do complex look ups in other beans. It lets me have a
> bean that contains (somtimes iterated sometimes multiple) beans. It lets
> me hide the data model (at least the way I use it). So if the data model
> changes, I have one place, the Bean.
Just as a note, it will be common even when using DynaActionForm to
actually implement a subclass so that you can have custom reset() and
validate() methods. You can still avoid having to write all the property
getters and setters.
Support for pre-initializing indexed/mapped/nested properties is currently
clumsy in DynaActionForm (I find myself doing it in the reset() method) --
that is something I want to work on.
> I also have other uses for my Beans, not just Struts, ie. SOAP.
> Say I have my BaseFrmBean that has a DAO. The DAO has a complex sql join
> string (Some of my clients have a 16 way joins in DAO). Then my Form
> Beans have getters and setters (that use the DAO). When I look at the
> Strus applications I have writen, my getters and setters are somtimes
> dozens of lines long in every FormBean. I could post good long setters
> or getters examples.
If you are accessing the DAO from a form bean, you are doing things wrong
IMHO. And that would be true whether you use standard ActionForm beans or
DynaActionForm beans.
Form beans (of any flavor) have one and only one purpose in the Struts
architecture -- to maintain a server side copy of the current input fields
for the HTML form that they are associated with. Any sort of business
logic, or access to other tiers, should be coordinated by Actions instead.
There are two common scenarios for this (both illustrated in the
/struts-example webapp):
* Set up and prepopulate the data to be presented on the form
in the first place. This is typically done by a "setup" type
action that *itself* calls your business logic or DAO layer to
set up the fields in the form bean (and sets up any other
non-form-bean beans that you need). See the "editRegistration"
and "editSubscription" actions in the example app.
* Update the business logic or DAO layer after a form has been
validated. Again, this should be done in an action that pulls
the data out of the form bean, performs any necessary data conversions
(remember, the form bean will generally have String fields for things
that will end up as numbers, so that invalid input data can be
redisplayed correctly), and calls your DAO methods. See the
"saveRegistration" and "saveSubscription" actions.
The form bean (standard or DynaBean based) is part of the *view* layer of
a Struts based application. It has no business directly manipulating the
model layer underneath, IMHO.
> Say I have a CLOB, or other. Or (manual) O/R mapping.
> Or lets say I have dynamic options on a page. So I need a getOption and
> getOptions. With a 1:1 bean to a page it makes it easier.
> Or Multi Line updates. Dynabeans are only for simple. So sometimes I
> would do XML code sometimes Java, so why not Java Beans all the time.
> In a real world application, things are not straig forward, and a getter
> and a setter can do anything. Dynabean would only be for simple things
> or a prtotype.
> Also... debuging. MultiLine updates with master detail gets a bit complex.
> I can unit test the FormBeans, before ever using it in Struts!
> Or errors. If the getter comes from another place.
> Or row based security.
>
> But for the same reason I do not like the SQL tag. I like the phsyical
> separation of the data model. An bean enitty does not have to be a
> single table.
I don't like SQL tags either :-). But aren't you (in effect) doing the
same thing when you hide DAO-manipulation logic directly inside your form
bean getters and setters? You are directly binding your form beans to the
underlying data representation, and will therefore have to modify them to
reflect model tier changes anyway.
For example, consider an app whose initial persistence layer is based on
direct JDBC access, and you need to migrate to code generated by an O/R
mapping tool (or switch to entity EJBs). Properly separated form beans
should be totally unaffected by this change (unless you happen to add or
remove properties at the same time, which will of course need to be
reflected).
This matters a *lot*, because in most environments you will have a lot
more form beans than you have model-layer beans (or associated value
objects).
> I realy like the clean lightweight MVC. A Bean is simple and powerfull
> and great architecture for people to whatever they want. I like
> practical and KISS. Skiping a layer can get confusing to new people and
> does not work when it is a realistic application.
That's interesting ... the technique you describe sounds to me like you
*are* trying to skip a layer (the controller :-).
> Also, most IDE's now generate the getters and setters, based on a
> property list you give them (CodeGuie from Omnicor I use) so if it's
> simple, it is simple.
>
> Vic
>
Craig
>
> Craig R. McClanahan wrote:
> >
> > On Tue, 30 Apr 2002, Struts Newsgroup wrote:
> >
> >
> >>Date: Tue, 30 Apr 2002 07:25:01 -0700
> >>From: Struts Newsgroup <[EMAIL PROTECTED]>
> >>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >>To: [EMAIL PROTECTED]
> >>Subject: Re: DynaActionForm example
> >>
> >>Subject: Re: DynaActionForm example
> >>From: Vic Cekvenich <[EMAIL PROTECTED]>
> >> ===
> >>Err... just a note: I am not sure if Dynabeans is the best parctice.
> >>Regular beans isolate the application a bit better.
> >>my 2 c.
> >>Vic
> >>
> >
> >
> > OK Vic, I'll bite ... how is using a DynaBean for your form bean any
> > different than a standard ActionForm bean? The only difference I can see
> > is whether or not you have to write an extra class yourself, or let Struts
> > configure it dynamically.
> >
> > Craig
> >
> >
> >
> >>James Mitchell wrote:
> >>
> >>>The struts-example uses it for Logon.
> >>>
> >>>
> >>>struts-config.xml
> >>>-----------------------------------
> >>>...
> >>>...
> >>> <form-bean name="logonForm"
> >>> type="org.apache.struts.action.DynaActionForm">
> >>> <form-property name="username" type="java.lang.String"/>
> >>> <form-property name="password" type="java.lang.String"/>
> >>> </form-bean>
> >>>...
> >>>...
> >>> <!-- Process a user logon -->
> >>> <action path="/logon"
> >>> type="org.apache.struts.webapp.example.LogonAction"
> >>> name="logonForm"
> >>> scope="request"
> >>> input="/logon.jsp">
> >>> <exception
> >>> key="expired.password"
> >>>
> >>>type="org.apache.struts.webapp.example.ExpiredPasswordException"
> >>> path="/changePassword.jsp"/>
> >>> </action>
> >>>...
> >>>...
> >>>
> >>>
> >>>
> >>>
> >>>logon.jsp
> >>>--------------------------------------
> >>><html:form action="/logon" focus="username">
> >>><table border="0" width="100%">
> >>>
> >>> <tr>
> >>> <th align="right">
> >>> <bean:message key="prompt.username"/>
> >>> </th>
> >>> <td align="left">
> >>> <html:text property="username" size="16" maxlength="16"/>
> >>> </td>
> >>> </tr>
> >>>
> >>> <tr>
> >>> <th align="right">
> >>> <bean:message key="prompt.password"/>
> >>> </th>
> >>> <td align="left">
> >>> <html:password property="password" size="16" maxlength="16"
> >>> redisplay="false"/>
> >>> </td>
> >>> </tr>
> >>>
> >>> <tr>
> >>> <td align="right">
> >>> <html:submit property="submit" value="Submit"/>
> >>> </td>
> >>> <td align="left">
> >>> <html:reset/>
> >>> </td>
> >>> </tr>
> >>>
> >>></table>
> >>>
> >>></html:form>
> >>>
> >>>
> >>>LogonAction.java
> >>>--------------------------------------------
> >>>...
> >>>...
> >>> // Validate the request parameters specified by the user
> >>> ActionErrors errors = new ActionErrors();
> >>> String username = (String)
> >>> PropertyUtils.getSimpleProperty(form, "username");
> >>> String password = (String)
> >>> PropertyUtils.getSimpleProperty(form, "password");
> >>>...
> >>>...
> >>>
> >>>
> >>>
> >>>JM
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Parmar, Dipakkumar [mailto:[EMAIL PROTECTED]]
> >>>>Sent: Monday, April 29, 2002 11:38 PM
> >>>>To: Struts Users Mailing List
> >>>>Subject: DynaActionForm example
> >>>>
> >>>>
> >>>>can anyone point me the DynaActionForm example?
> >>>>i could not able to find it.
> >>>>
> >>>>Tx in advance.
> >>>>Deepak
> >>>>
> >>>>--
> >>>>To unsubscribe, e-mail:
> >>>><mailto:[EMAIL PROTECTED]>
> >>>>For additional commands, e-mail:
> >>>><mailto:[EMAIL PROTECTED]>
> >>>>
> >>>>
> >>>
> >>>--
> >>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> >>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >>>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >>
> >>
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
