On 11/09/2004 06:26 PM Joe Germuska wrote:I think this is exactly the point. JSF's controller model may not scale to a large application. However, in the Shale proposal, JSF's controller model is only being asked to control the view. Right now, Struts doesn't have a separate concept of a "view controller," and I am finding that a limitation. I would like a clean facility for prepopulating forms from system data which interoperates with the existing mechanism for prepopulating forms when validation fails and the user must try again. I would also like a clean mechanism for doing certain kinds of page preparation based on the destination page rather than the processing action. I feel that this cleans things up and supports a nicer separation of concerns. Neither of these is easy in Struts today, and I think the way forward is to more explicitly model a "view controller" subcomponent. I think Craig believes that JSF has already done that. I still have to find out for myself.
Joe,
have you tried the Post Redirect Get (PRG) pattern? I use it to seperate out the submit from one page from the retrieve for the next page. It required a little method on my BaseAction to append the primary key of the data onto the redirect URL, but otherwise it's simple enough and does what you want.
e.g. I want insert a hotel, and go on from there on success to add rooms.
In the simple old scenario, the insert form would submit and come back with the "add rooms" screen, which would have the URL /hotel/insert.do and have been set-up by the HotelAction class.
With PRG, on finishing the hotel/insert.do insert, the forward is a redirect to the hotel/addroom.do action.
I started doing this for the sake of the URLs. What I like about issuing a redirect is that the user then sees a comprehensible URL. I quickly found that it gives me flexibility to a completely 'OO' the actions (HotelAction and RoomAction), with all the advantages of that.
I haven't tried this method; we've worked out a system here at my day job that works, but I believe that Struts should support this more directly. I would prefer to have clearer URLs, as you do, and that's one thing that our model doesn't have. I'm wondering if there are other cases where the primary key appending wouldn't be complete, although none come to mind. I sort of feel like the extra overhead of a redirect is less than perfect, but it's certainly the only way to get the URLs the way you want them. I don't know if that's worth it to me or not, but it is nice.
I obviously have an affinity for the way we do it here (something I elaborated about in more detail in this list post: http://article.gmane.org/gmane.comp.jakarta.struts.devel/22034) but I would be happy to adjust my ideas if we got anything approaching a consensus from list members. I'm looking for more clear buy-in from folks before I try to forge out and code anything around this. My point being that even in a Struts 1.x timeframe, this could be easier. Maybe this really doesn't bother anyone but me -- sometimes I get that feeling!
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place."
- Carlos Santana
