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). 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]>
