Sorry about the delayed reply. AT&T Broadband was down for most of yesterday :-( There are definitely a lot of possible ways of constructing this pattern. The FormBeanUser implements ControllerSingleton because there really isn't any point in creating new instances of FormBeanUser for each request... it maintains no request-specific state. You probably wouldn't want to use your Controller base class for this because it probably extends ThrowawayBean, which populates each fresh bean instance no matter what. Since all you are really looking for is a way of persisting a Controller bean across requests, you could modify the FormBeanUser to eliminate the bean population step and actually create/get your Controller class. The perform() would simply call through to Controller's perform(). You would have to have some way of figuring out what "step" you are on, though... either by guessing from the parameters or by adding an extra interface contract between the two objects. The modified FormBeanUser could actually be a generic adapter, taking the Controller class name from the maverick config file in init(). Is this what you're looking for? Jeff Schnitzer [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -----Original Message----- From: Dan Finkelstein Sent: Mon 4/15/2002 11:43 PM To: maverick Cc: Subject: RE: [Mav-user] Can a form be spread over two pages? 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/vn d >.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
<<winmail.dat>>
