On Thu, 13 Jun 2002, John Yu wrote:
> Date: Thu, 13 Jun 2002 11:53:59 +0800
> From: John Yu <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: FormBeans ... as an Interface.
>
> At 03:28 pm 12-06-2002 -0700, you wrote:
>
> >If you do that, just be aware that you are expressly violating the purpose
> >for which ActionForm was created in the first place, and are also
> >establishing a dependency in your model classes on both Struts and the
> >servlet API -- which can make such classes less reusable.
> >
> >Craig McClanahan
>
>
> To a certain extent, this consequence is 'historical'. If the formbean api
> had been decided not to tie up to the Struts and servlet API, we would not
> see this dependency problem. So, I think one outcome of this discussion is:
> 'does it make sense to "correct" this historical issue to allow less
> restrictive usage of formbean by changing the formbean api?'
>
"Over my dead body.
Craig McClanahan
06/12/2002"
(Note that, totally aside from any discussion over whether this *should*
happen or not, changing this would break every single form bean in every
single Struts-based app in existence, which is *not* a good idea :-)
> To me, the discussion is getting a bit religious, pragmatism vs
> idealistism. On one hand, from my consulting experience, I share Vic's
> sentiment. On the other hand, I find it's inelegant when the boundary of
> the layers gets blur. (Hmm, it seems I'm not adding any value here...)
>
I think I might have some claim to knowing the actual history here :-).
Up to the Struts 0.5 release, ActionForm was in fact an interface.
However, what became apparent is that people were either misunderstanding
or misusing them, so it was deliberately changed (by me) to be a class
instead, *precisely* because of the issue that is the heart of this
discussion thread.
Consider the "user database" in the Struts example application. In 1.1,
at least, it is nicely factored into a DAO interface
(org.apache.struts.webapp.example.UserDatabase) that can be implemented
with a variety of underlying technologies (the default is a HashMap backed
by an XML file, but you could use either direct JDBC calls or EJBs quite
easily). Note that this interface, and the related User interface, have
zero dependencies on Struts or servlets -- therefore, this abstraction
(and the underlying implementations) can be used in *any* application that
needs to talk to this data.
First, let's write a Struts-based app to maintain users. That's pretty
straightforward -- define an ActionForm (or DynaActionForm) corresponding
to the User interface, and a few pages and Actions (or use something like
Ted's example app) and you're done.
Now, consider that you want to write a cron job (under Unix) that
periodically scans the /etc/passwd file and updates the corresponding
database rows. Because the UserDatabase and User interfaces are totally
independent of Struts, they can be reused as is.
If you had used an ActionForm directly as the User object, instead of
following this suggested path, I'm really interested in hearing how you
are going to explain to your system architect the rationale for requiring
struts.jar and servlet.jar on the classpath of a batch CRON job ...
Vic can encourage this usage of ActionForm for model layer objects all he
wants -- he's free to use Struts any way he feels is appropriate. Just
understand that the inventor of Struts thinks that this is a really really
really bad idea. I am not interested in making it easier for Struts users
to violate MVC principles in this particular fashion.
(NOTE: In my "day job" role as lead for JavaServer Faces -- JSR-127 -- I
can confidently speculate that the current Struts attitude about
server-side state objects will become apparent in JSF as well, so you
might as well get used to it :-)
> --
> John Yu Scioworks Technologies
> e: [EMAIL PROTECTED] w: +(65) 873 5989
> w: http://www.scioworks.com m: +(65) 9782 9610
>
> Scioworks Camino - "Rapid WebApp Assembly for Struts"
>
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
