> -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich
==///== > > Craig R. McClanahan wrote: > > > > > > > There's a couple of variations on the theme that are > possible, but I can think > > of at least three layers of something that might be called > a "form bean" in the > > conceptual sense: > > > > (1) A set of typesafe field names and corersponding values > > where the application doesn't have to worry about maintaining > > values across requests. > > - Variation: dynamically add and remove fields as needed > > - Variation: allow non-typesafe fields > > - Variation: allow fields that can have multiple > values (arrays) > > - Variation: represent data hierarchically instead of just > > a name-value map (bean properties, nested expressions, > > XML DOM, what have you) > > > > (2) The above plus a mechanism to define validation rules > (correctness > > checks) on the field values that are independent of physical > > presentation > > - Variation: hard coded logic for validations (i.e. > the original > > validate() method in Struts ActionForms. > > - Variation: pointer to a configured set of validation rules > > that is abstracted from presentation considerations. > > > > (3) All of the above plus event handlers for UI events that change > > the state of the field values -- perhaps in the same bean, > > perhaps somewhere else. > > > > A type (1) or type (2) form bean is really better thought > of as an abstract way > > to pass the input data for some sort of business > transaction between tiers, or > > within tiers. A type (3) form bean would definitely live > in the presentation > > tier, and not be used between them. For all three of the > cases, though, we > > probably want to invent a different term than "form bean" > because that seems so > > conceptually tied to presentation only. Transaction Bean? > Input Bean? Data > > Transfer Object :-)? > > > Can't it be just one good old View layer "thing" that maps the > properties and it's still called formBean? KISS > > Don did not link XMLForms good, here are better links for a > real fun read: > > http://webservices.xml.com/lpt/a/ws/2003/01/29/cocoon-xforms.html > > http://www.cocoonhive.org/xmlform/index.html > > I like that Pico is lightest IoC and do not see a need for a Bean > Factory, etc.. So there should be some talk of Spring vs Pico. > > > So far, if it's built on top of > -IoC > -with "XMLFormBean" (as option, since XML can be slow right > now, so it > needs to support backward compatible FormBean) > -an execute(context) Action iterface, > -chain request procesor filter interfaces > -HTML tag to support XML Submit (including multi row) > -JDK 1.4 > -Clear testing interface to major user components. > > That could be the broad stroke major center pieces. It is > same design as > Struts 0.6 with each component refactored, same diagram. > > > There are several smaller pieces, but if Struts can stay > light without > too many moving parts, better, people can put arms arround it. > XML config wishes: > - all xml files be able to extend like tiles, like in Validator > - move form beam declaration section to validator, no need to > do it 2 times. > - move all tiles xml to struts config, and get rid of tiles.xml > - have a forward to a tile declaration allow you to name the "base" > definition and tile to replace, even maybe have tile part of > "* forward" > or what ever Don's thing is called. > This would involve XML namespacing for Struts DTD, but Ted has already addressed, if you want to make gigantic configuration file. I think the simplicity is in the modularity of the XML files rather than having a monolithic mess/. > I still kind of think maybe DAO interface should be there, we > learned a > lot about DAO since. > Data Model should be agnostic regarding Struts. > (I still think one or 2 people should do it in 48 hours from start > else... it's design by comittee) > > .V > Keep in mind that Spring has its own Model View Controller package, and Rod Johnson berates Struts 1.0 a little in his book "Expert One on One" ... concerning ActionForm themselves. Having spoken with Don Brown, I can see the benefits now of the BeanWrapper and the [Xml]BeanFactory in Spring. Creating a graph of objects from an XML file is pretty handy for certain situations. I can see the light of the joke. Objects just "Spring" into life from literal paper. I guess the decision here will be political. "Can we just take or borrow the org.springframework.beans.* of your framework?" Hmmm. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *********************************************************************************** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbs.co.uk/CBFM http://www.rbsmarkets.com ******************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
