I was on this track in another thread where I was saying.......

"What if ActionForm was an inner class to a Value object.  Or, what if a
Value object had a reference to an ActionForm which when filling with
parameters we did ActionFormValue.getActionForm(), filled it, complete "does
it exist" checking and non-business object validation checking, and then do
a ActionFormValue.setActionForm(ActionForm myform) to set it back, which
would fill the ActionFormValue object with the values in the ActionForm. An
"ActionValue" could hold 1 or more ActionsForm(s) , or could take ActionForm
as a parameter, with which it would copy and "nativeize" the data in the
ActionForm.  In this case an ActionValue would hold specific fileds for the
beans it uses."

My point here,....though I hope it is apparent, is that we need to send
value ojects through the system in a way in which it can complement/work
with Struts.


----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 8:03 AM
Subject: Re: [EJB] Design Patterns (was JavaReport ...)


> What I'm working on now are patterns for Struts development that can be
> used with or without Enterprise Beans. As mentioned, the J2EE blueprints
> are mostly about development patterns, and Enterprise Beans are one part
> of implementating those patterns. This work is the second part of the
> Strut by Strut series ("Stepping out").
>
> I had a long discussion with a BEA Weblogic employee the other day about
> this very thing. I think we need to more strongly seperate the J2EE
> patterns from the Enterprise Bean implementation. The idea being we
> should introduce people to the pattern first (presentation beans / data
> access beans / value object beans / helper beans), and then show where
> Enterprise Beans plug into that. Or, where you would roll your own.
>
> On the Struts front, while it is often the case that the ActionForm
> beans end up looking like many of your internal beans, there are
> important differences. For example, ActionForm beans should be immutable
> except by the actor, meanwhile many of your internal beans should be
> immutable except by the model. ActionForm beans need to use Strings as
> the primary type, but your internal beans may need native types to
> commune with the business logic beans. You really only need ActionForm
> beans to get input from the actor. When sending read-only views back,
> you can use any kind of bean you want (with the bean tags), so long as
> it has a reasonable toString(). It seems wasteful at first, but in the
> big picture, it seems like treating ActionForm beans as HTTPD
> throw-aways is the only way to keep the application loosely coupled, and
> able to attach to other environments later.
>
> Of course, data transfer becomes a big issue when you have to ferry
> things from ActinForm beans to data-access beans (and then back again in
> the case of an update). What I'm looking at now is using hashmaps as a
> standard data transfer agent. If the ActionForm can return a hashmap
> that matches the data access bean you can use BeanUtil.populate() to
> make the switch. Coming back later, if the value object bean returns a
> hashmap, you can use BeanUitl.populate() to fill your ActionForm bean
> (for an update). This would mean that your ActionForm bean design
> "knows" about your value object bean design, but I think that's OK
> (though the inverse would not be OK).
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
>
> "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" wrote:
> >
> > To Anyone It Concerns,
> >
> > Although I'm relatively new to EJB's, I'm listed on the 1.1 TODO list
> > to add better EJB support/design patterns.  Ideas that anyone has about
> > things that they'd like Struts to do with EJB's will definately help me
> > along with this and help Struts quiet this EJB fud. I'm looking to get
> > started on this soon, and anyone who wants to is more than welcome to
> > help me out.
> >
> >  - Mike
>

Reply via email to