got to cast my vote with Craig - adding all that stuff to form bean is IMHO bad
practice and leads only to trouble.
Dave
Struts Newsgroup (@Basebeans.com) <struts%basebeans.com on 04/30/2002 01:25:01
PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: David Hay/Lex/Lexmark)
Subject: Re: DynaActionForm example
Subject: Re: DynaActionForm example
From: Vic C <[EMAIL PROTECTED]>
===
Controller I use as contoling where to go(next page), navigation, and
what to do,to ask the bean to populate, to save, etc, be end point for
all errors, exceptions, set FKs on inserts, ask for validation, etc. but
not for DAO.
By using the FormBean as a model (form bean has the DAO) instead of as
the view(the controler has the DAO) I avoid the need to re-map
properies. To me that is cleaner MVC than if the Controller has DAO.
What if you need to re-use the beans elswhere? DAO could be anything,
even EJB. I tried using action for DAO at first apps. Then I found it
cleaner to do JavaBeans as DAO.
From a practical applied point. I like formbeans over dynabeans, I like
FormBean as a model. It is simpler to use the Beans as the model, than
in esence have 2 sets of beans. If that is the problem dynabeans is
solving, with ValueObject, etc.... again, dynbeans are not realistic
enough for a real world application, IMHO. Struts should remain a light
weight simple framework hopefully, it should not start imposing, so
people can use JavaBean as FormBeans.
Some very complex applications that are well architeced and done quickly
in Strtus becuase of the OO and MVC capabilities of Struts.
Vic
Craig R. McClanahan wrote:
>
> 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]>
>
--
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]>
