Jeff, Wow... that's really quite cool. I can't believe how little code is in FormBeanUser -- very elegant!! I spend a bunch of time trying to figure it out, and have a couple of questions:
1. Why does it extend from ControllerSingleton instead of Controller? I don't see any "local variables", and since the bean is being stored in a session attribute wouldn't a Controller base class work ok? One reason I'm asking because I have a lot of functionality in a base Controller class that I extend for all my other controllers, and it seems like a nuisance to have to maintain that functionality in two places. 2. Would this be possible? Could we add this basic functionality to a Controller.perform()-extended method so that any forms I have in my view, could be re-written as N pages without any controller changes? On my site almost all of the forms are one page. But I can imagine here and there, some spreading to two or three pages over time (and maybe some N page forms contracting to one page). It would be cool if my standard forms-processing handled both cases. Under one-page situations, the perform just processes the form as though it were the last page. Under n-page situations, all but the last page use your formbean technique to stow away the bean. Thoughts? I really appreciate your effort. Dan At 07:00 PM 4/15/02 -0700, Jeff Schnitzer wrote: >I think this is a case where the struts-like controller pattern (with >separate FormBeans) is more appropriate. I would suggest using a >ControllerSingleton for both pages, and have the first one store the >FormBean in the http session. The second one would simply get the bean >out of the session rather than create a new one. > >[clickety click click...] > >I just checked in a ControllerSingleton base class which takes care of >the basic legwork for you. Try looking at >org.infohazard.maverick.ctl.FormBeanUser: > >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/maverick/src/java/org >/infohazard/maverick/ctl/FormBeanUser.java?rev=1.2&content-type=text/vnd >.viewcvs-markup > >All you should need to do is override makeFormBean() (the first >controller makes it and puts it in the session attributes, the second >just gets it out of the session attributes) and voila, your data is >easily populated across separate forms :-) > >BTW, I haven't actually tested this, so let me know if you have any >trouble. Incidentally, it wouldn't be too difficult to extend >FormBeanUser so that real Struts Actions, unmodified, could run in a >Maverick environment and get all the advantages of transforms, shunting, >etc. > >Jeff Schnitzer >[EMAIL PROTECTED] > > > -----Original Message----- > > From: Dan Finkelstein [mailto:[EMAIL PROTECTED]] > > Sent: Monday, April 15, 2002 2:00 PM > > To: maverick > > Subject: [Mav-user] Can a form be spread over two pages? > > > > Hi -- > > > > I would like to design the UI of an input process, so that the user is > > presented with two screens (instead of just one), each which would ask >for > > some of the necessary parameters. > > > > What I would really like to be able to write the code is such a way >that > > only the view has to be modified, should a skin with three (or four..) > > input screens be implemented. It appears that there is a implicit > > coupling > > which couples the pages to the controller more tightly than I would >like. > > > > I was thinking of what might work: perhaps a special feature in the > > controller, which will support multiple pages. Hidden fields would be > > embedded in the forms of each page, and the perform() method would >figure > > out which page has been submitted. Then, I suppose, the controller >would > > have be told to persist until the next last call to perform() or >hidden > > fields in the html form could hold already entered fields. I'm not >quite > > sure how I would implement this, but perhaps if this were put in the >base > > Controller class, all forms would be able to take advantage of this > > functionality for free. > > > > Any thoughts to help me out? > > Dan > > > > > > _______________________________________________ > > Mav-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/mav-user > >_______________________________________________ >Mav-user mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/mav-user _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
