Joe most recently mention this sometime last month: http://marc.theaimsgroup.com/?l=struts-dev&m=110842402707799&w=2
Yep, I was involved in that thread :) The one thing I will say is that the whole discussion of "view controllers" and "page prep" is really different than what I implemented. It is similar without question, but not the same. In fact, and I say this without ego (which is a rare thing, I will admit! :) ), I think there is a certain uniqueness to what I did that is at the very least interesting.
Aside from this, an email I sent to you (well, on the user list, but on the thread where you mentioned this) also linked to a couple of threads discussing this feature. That mentioned a few alternatives, including one from me. I even noted that the message was almost a year old. :) http://marc.theaimsgroup.com/?l=struts-user&m=111029587900454&w=2
I didn't read that one until now. Interesting! However, I would make the same comment... what I did is, while similar, still different.
The difference by the way is the generic nature of my solution... it doesn't really say much of anything except "for any action mapping and/or forward, you can execute any number of arbitrary methods of arbitrary classes". It doesn't push you towards a page-centric approach, it doesn't force class structures on you, it doesn't tie forms to forwards or this to that or anything like that. It's very open-ended.
There may be an argument to be made that it's *TOO* generic and open and therefore open to serious abuse. I could see someone making that argument.
> The 1.3 support includes a change to the config DTD. A 1.2 friendly
change could look something like:
<forward name="success" path="/page.jsp" className="package.SpecificSetupActionForward"/>
package.SpecificSetupActionForward would either extend a SetupActionForward, or implement a SetupActionForward. In either case, a setupView() method would be implemented/overridden.
This is one of the things I was seeking to avoid with my implementation... I didn't want the classes to be anything other than POJOs. I didn't want to limit the developer to a single setup method per class. I also wanted to allow for any number of these calls per forward. Certainly it can be debated whether that is too much power, but those were my goals. This suggestion wouldn't accomplish those goals.
The action's return could look like:
return ViewSetupUtil.setupForward("success", mapping, request);
ViewSetupUtil.setupForward() would call findForward("success"), check if it's an instanceof SetupActionForward, then call the setupView() method and pass the request. Depending on what the setup entails, a user may want to break it down into separate statements in the action so he can check conditions and alternatively return a different forward altogether.
But this intrinsically ties this to a forward, and it also entails more code in an Action. I'd prefer a purely declarative answer. I also think we should be able to do this at the action mapping level as well as the forward level. Also, would this work for global forwards? My implementation does.
If you want POJO support, you can do something like:
<forward name="success" path="/page.jsp" className="package.SetupActionForward">
<set-property property="setupClass" value="package.MyForwardSetup"/>
<set-property property="method" value="setupMethod1"/>
</forward>
I personally wouldn't like this as I think set-property is too easy to abuse (and might be already). For instance, one can do:
<record> <fieldName>FirstName</fieldName> <fieldValue>Frank</fieldValue> <fieldName>LastName</fieldName> <fieldValue>Zammetti</fieldValue> </record>
Perfectly valid of course, but not as good, in my mind at least, as:
<record> <firstName>Frank</firstName> <lastName>Zammetti</lastName> </record>
Aside from being shorter, which is good for numerous reasons, the second to me is just a tad clearer in meaning. Not a huge difference I admit, but a bit. I view set-property like the first example.
In this case, SetupActionForward would instantiate the named class and call the method and pass parameters. Either way, it'd work even without any changes to Struts core. :)
Agreed, could work without changes to the core. But I think it makes a worse compromise: it requires changes on the part of the application developer. Again, purely declarative was one of my goals.
There are other variations that can be made, of course.
I very much want to discuss them! However, in my mind, any solution must meet the following criteria:
(1) Must be purely declarative
(2) Must NOT require changes to existing applications
(3) Must work at the action mapping and forward level (both local and global)
(4) As per everyone else' opinion, must NOT change any Struts classes
(5) As far as I'm concerned, must use POJOs and must allow for an arbitrary number of method calls in any number of classes per mapping/forward
My implementation deals with all but #4. Unfortunately, that's the one point that is killing it being accepted I think :)
As far as sharing this to other people, I've done something similar with http://www.rabago.net/struts/redirect/. That one even involved a custom request processor and the use of a base action. And yes, people actually use it. :) Of course, sometimes I also just point them to an attachment I made to Bug 866.
That's actually quite cool! :)
Hubert
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
