Robert wrote:
> I really like the idea of what you are stating here Yan. Do you use
> JavaBeans (business objects) at all, or just the XML state? If so, do
> you then transfer the state to you business objects?
>
> What we have come across often is that a form might support multiple
> business objects. While you can do this with struts by having the
> FormBean talk to your multiple objects, it isn't exactly intuitive
> (well, for me).
Precisely! that is so true, who says that there is a one to one relationship
between View and Model? of course, although FormBean
really should be considered Model, but more like a psedo model,
or an abstraction layer object, kinda of like a boundary object in a way,
nevertheless, the whole process is a bit painful?
> While I like what the FormBean is designed for, an
> adapter to the domain objects, some of our clients have trouble with the
> hard-connection they have to the form.
I think Struts is slightly forcing some of the issues, consequently making
things less flexible. This approach would work wonderfully for
simpler projects, but I am not sure when the scope of the project
increases.
>
>
> I never really thought of the dynamic form issue, although that is a
> good one to consider.
>
> Robert McIntosh
>
> -----Original Message-----
> From: Yan Zhu [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 14, 2002 6:13 PM
> To: Struts Users Mailing List
> Subject: Re: struts' approaches
>
> Alex Paransky wrote:
>
> > Somewhere, I read that dynamic forms are a weakness of Struts. It
> should be
> > coming in the next version. For now, one has to resort back to
> general
> > basic JSP development for creating dynamic forms. What specific
> situations
> > did you have in mind?
>
> The relationship between the view (JSP) and the model (Java Beans)
> are often
> not
> as simple (unless you are doing some simple apps) as Struts want/need
> them
> to be. Sometimes what the view need to display is based on the
> information
> provided
> by the model, but not necessarily exactly like the model, furthur
> maniplulation
> of the
> data is often needed. Seems to me there are a lot of real practical
> problems in
> large
> apps are not addressed by Struts.
>
> By the way, I am sure some of my problems are caused by a lack of
> understanding
> of Struts, I only been looking at it for a few hours in the last two
> days, so I
> am sorry
> if I missed something in the docs.
>
> Let's take an example, let's say I have a form with 50 fields filled
> with
> text, combo
> boxes and what have you html controls up there. Currently I am handling
> that in
> this
> fashion: I name the controls smartly for those ones need to be updated,
> for
> example,
> fldName, fldAddress, etc, by the time of the update, I simply loop
> through all
> controls
> with fld prefix, and update a xml tree based on the values.
>
> So what's so good about this approach? well, I never have to make
> any changes
> to
> my underlying objects like those formobjects struts are so fond of. I
> can add any
> fields
> on the form as I wish, and my xml tree would grow accordingly. I perseve
> my state
>
> in the xml tree.
>
> Maybe Struts addresses this problem in a different way?
>
> yan
>
> >
> > -AP_
> >
> > -----Original Message-----
> > From: Yan Zhu [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 14, 2002 2:10 PM
> > To: Struts Users Mailing List
> > Subject: struts' approaches
> >
> > I been looking at the struts' stuff for two days now, and
> > been a newbie don't really have any real experiences with it.
> > However, I do have some experiences with developing j2ee
> > applications with jsp, ejbs etc. I feel that there are a lot of good
> > things in struts, such as implementation of the MVC and some
> > of the tags, but I feel in certain situations what struts provide will
> > not be good enough for large, complex, dynamic applications. For
> > example, mapping form fields to form beans will be a pain in
> > the butt in certain situations. Has anyone used Struts for anything
> > of a medium to large size projects with considerable complexity?
> >
> > thanks
> >
> > yan
> >
> > --
> > 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]>
