DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33935>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33935 Summary: Addition of setupItems capabilities to Struts Product: Struts Version: 1.2.4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Unknown AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] Summary ------- A common question that comes up often in the Struts developer community is how setup functionality can be done for a page. JSF has a prerender() method, other frameworks have the concept of page prep classes. There is no standard way of doing this in Struts at present however. Well, now there is: setupItems! Simply put, setupItems are a new child element of <forward> and <mapping> elements in your struts-config.xml file. They inform Struts about a class and a method within that class that you want to be executed every time the action is used, or the forward is selected. For instance, a simple example... Let's say you have a number of pages in your application, and some of them contain a dropdown that has the same values. You want to read those values from a database. There are numerous ways you could accomplish this, but no standard approach. With setupItems, you could write the following in your struts-config.xml file: <action path="/page1" type="com.omnytex.setupexample.action.TestAction"> <setupItem setupClass="com.omnytex.setupexample.setups.SetupClass1" setupMethod="setupMethod1" /> <forward name="defaultForward" path="/page.jsp"> <setupItem setupClass="com.omnytex.setupexample.setups.SetupClass2" setupMethod="setupMethod1" /> </forward> </action> This will result in SetupClass1.setupMethod1() being called BEFORE the execute () method of TestAction is called, and also in SetupClass2.setupMethod1() being called AFTER execute() completes *IF* the forward returned by TestAction is defaultForward. The setup classes that you call on are POJOs, there is no interface to implement, no class to extend, and no technical restriction on what you do in them. There may be practical limits though; you probably don't want to be reading from a database if the class is used a lot. But that is all completely up to the application developer, nothing is imposed on you. You can add as many <setupItem>s to mappings and forwards as you wish and they will all be executed in the order they are written in struts-config.xml. You can also add <setupItem>s to global forwards the same as local forwards. They can of course be added to any type of mapping, including ActionForwards. The setup classes are constructed and destroyed with each usage, they are NOT shared like Struts Actions are. This is good and bad of course, but you need to be aware of it either way. I am attaching a ZIP archive that contains all the changed Struts classes (4 changed classes, 1 new one) as well as a complete sample webapp that demonstrates the new functionality, as well as serves as a unit test of sorts for it (I suggest just running it to see, I think it will be pretty clear at that point). The archive also includes the required updated DTD, as well as a complete struts.jar with the required updates. A developer should be able to just drop the JAR into an existing app, point their struts-config.xml at the updated DTD, and they should be all set to use setupItems. I will be trying to attach diff patches to this ticket some time today to make it easier on the Struts team, should they decide to add this. I've never used diff before though, so it's a small learning experience. It is my hope that this is useful to the community. I offer it up for addition to Struts itself, but that is of course not up to me. Please feel free to contact me with any suggestions you have or problems you find on the Struts User or Developer mailing lists, or directly at [EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
