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?
>
I do use a home grown xml binding java bean. My business object
is the superset of my xml state, my BO can perform methods besides
the state of course, but they are all XmlObject type.
>
> 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). 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 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]>
