I'm actually not throwing SQLExceptions-- instead a generic application exception bubbles up from the DB interaction within an object repository that populates the form.
The problem for me is that if I have an array of items within the form, I may not need to know the state of the individual items in the reset() method, but I at least need to know how many there are and how to identify them, so that I can match up the user's entries with those in the model to validate and determine what if any model objects need to be updated. I'm not sure this violates Model2 principles or not: it seems to me in order to edit the model, you need to render it first in some form, and that form could have dynamic *structure*. For example, if you have an arbitrary number of checkboxes to reset that correspond states of objects in your model, you may need to consult the model to determine how many to put out there. Any thoughts anyone? BTW, thanks for input, Craig-- I think the fact that you are active on your user lists is a big reason your software is so successful. -JT -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, September 30, 2002 9:38 AM To: Struts Users Mailing List Subject: RE: SURVEY: Proper Way To Pre-populate ActionForms On Mon, 30 Sep 2002, Taylor, Jason wrote: > Date: Mon, 30 Sep 2002 08:54:46 -0700 > From: "Taylor, Jason" <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> > Subject: RE: SURVEY: Proper Way To Pre-populate ActionForms > > My problem with doing database lookups in ActionForm.reset() is that an > exception may occur and it's not as easy to handle as it when doing things > within the Action class (where you can just forward things to an error.jsp). > > > I find that if I trap the exception, the populate method may have problems > because reset() didn't complete and the controller will throw an exception > to the container's handler, and if I don't trap it, the controller again > handles the exception. > > Is this the reason you recommend not doing DB lookups in ActionForm.reset(), > or are there other considerations that make it undesirable? > That's a valid reason to be concerned (although the method signature of reset() isn't going to let you throw a SQLException anyway). My primary concern, however, is a more fundamental architectural principle. An ActionForm class is part of the view tier in the MVC architecture that Struts supports. As such, it should have no knowledge of where the data for the fields came from (for a pre-populate), or where it goes to (for the usual form processing after a submit). Putting any SQL logic into a form bean violates the layer separation, as well as increasing your maintenance burden when your DBMS table structure changs. > -JT > Craig McClanahan > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 30, 2002 8:43 AM > To: Struts Users Mailing List > Cc: '[EMAIL PROTECTED]' > Subject: Re: SURVEY: Proper Way To Pre-populate ActionForms > > > The struts-example app (which uses a separate action for the setup) is the > method that I recommend for manually setting up an ActionForm instance, > plus any other beans that need to be looked up and placed in request > scope. To remind you of the relationships, the actions and the JSP page > are named similarly: > > * editRegistration.do -- Set up the "registration.jsp" form bean > > * registration.do -- The input page for registration information > > * saveRegistration.do -- Save the new or updated registration > information to the database > > It's fine to rely on the auto-creation of the form bean if you don't need > to look up any database information (i.e. you're going to be doing a > "create" type transaction), where you just make your reset() method set up > all the defaults. However, if you're going to do an "edit" transaction > against existing data from the database, I prefer to look that up in a > setup action rather than make the reset() method have to go to the > database itself. > > Craig McClanahan > > > On Mon, 30 Sep 2002, Hohlen, John wrote: > > > Date: Mon, 30 Sep 2002 08:22:29 -0500 > > From: "Hohlen, John" <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > > To: "Struts-Help (E-mail)" <[EMAIL PROTECTED]> > > Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > Subject: SURVEY: Proper Way To Pre-populate ActionForms > > > > I was wondering what the overall philosophy is in the Struts Users > community > > in regards to pre-populating action forms? I sent a message out late last > > week asking for help on how to manually instantiate and pre-populate an > > action form (prior to forwarding to a JS) in Struts 1.1. That's when I > > realized this may be considered bad practice. Here are some comments I > > received: > > > > Eddie Bush: > > "No, no. Actions/Forms have a contract -- the form 'will' be created. > > You should not take this upon yourself. What you need to do is pre-face > > the page with a 'populate' action. Expect it to be there" > > > > James Turner: > > I can still point to cases where you need to manually pre-populate. > > For example, if you have multiple forms on a single JSP page, you either > > need to pre-populate the forms manually, or you'd have to daisy-chain a > > bunch of actions together, each one of which was responsible for > > pre-populating a single form. This seems clumsy to me. Maybe what we need > > is an authoritative way (i.e., an API) to instantiate DynaForms. > > > > What are others doing here? BTW, if manually pre-populating an action > form > > is acceptable, does it make sense to create a method in the "RequestUtils" > > package making this > > easy to do for a DynaForm (Struts 1.1). For example (code provided by > James > > Turner): > > > > ApplicationConfig appConfig = > > (ApplicationConfig)request.getAttribute(Action.APPLICATION_KEY); > > FormBeanConfig formBeanConfig = > > appConfig.findFormBeanConfig("myDynaActionForm"); > > String beanType = formBeanConfig.getType(); > > DynaActionForm bean; > > DynaActionFormClass formClass = > > > DynaActionFormClass.createDynaActionFormClass(formBeanConfig); > > return (DynaActionForm) formClass.newInstance(); > > > > Thanks! JOHN > > > > > > -- > > 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]>
