DO NOT REPLY [Bug 33935] New: - Addition of setupItems capabilities to Struts

[bu...@apache.org]

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: dev@struts.apache.org
        ReportedBy: fzammetti@omnytex.com


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
fzammetti@omnytex.com.

-- 
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org