We are taking a slightly different approach that you may like.
We are overriding ActionServlet to add two hooks, a
//execute BeforeAction event queue
if (!processBeforeAction(mapping,
formInstance,
request,
response))
return;
/**
* Called from overridden process() function Before the call
* to the Action perform and before the call to forward.
*
* PEPServlet passes control to the eventsDispatcher that
* looks up any registered event actions and executes them
*
* <p>
*
* @param request The servlet request we are processing
* @param response The servlet response we are generating
*
* @return <code>true</code> if the remainder of the standard
processing
* should be performed, or <code>false</code> if the response has
already
* been created so the calling method should immediately exit
*
* @exception IOException if an input/output error occurs
* @exception ServletException if a servlet exception occurs
*/
protected boolean processBeforeAction(ActionMapping mapping,
ActionForm formInstance,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
boolean continueProcessing = true;
boolean isBefore = true;
//create a new dispatcher
eventsDispatcher ed = new eventsDispatcher();
request.setAttribute("EventsDispatcher", ed);
continueProcessing = ed.perform( mapping, formInstance, request,
response, isBefore );
return (continueProcessing);
}
and
//execute AfterAction event queue
if (!processAfterAction(forward,
mapping,
formInstance,
request,
response))
return;
/**
* Called from overridden process() function after the call
* to the Action perform and before the call to forward.
*
* PEPServlet passes control to the eventsDispatcher that
* looks up any registered event actions and executes them
*
* <p>
*
* @param request The servlet request we are processing
* @param response The servlet response we are generating
*
* @return <code>true</code> if the remainder of the standard
processing
* should be performed, or <code>false</code> if the response has
already
* been created so the calling method should immediately exit
*
* @exception IOException if an input/output error occurs
* @exception ServletException if a servlet exception occurs
*/
protected boolean processAfterAction(ActionForward forward,
ActionMapping mapping,
ActionForm formInstance,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
boolean continueProcessing = true;
boolean isBefore = false;
//get the eventsDispatcher
eventsDispatcher ed = (eventsDispatcher)
request.getAttribute("EventsDispatcher");
continueProcessing = ed.perform(mapping,
formInstance,
request,
response,
isBefore );
return (continueProcessing);
}
Then the struts-config.xml has a new element
<events-mappings>...</events-mappings> that contains the event mappings.
The Mappings for events include the "Before" and "After" keys as well as a
Regular Expression event key that allows a single event to be 'registered'
for multiple Actions.
>From what you said, you want some logic applied prior to the
processActionForward and that is what we are doing.
Ollie
[EMAIL PROTECTED] writes:
> Hi Francois,
>
> I have been confronted to a similar problem while building a portal page
>including several components containing different <form>.
> I have written an Action associated to the portal page, and one action
>for
>each <form>. The main Action calls each component's action, and forwards
>to the
>portal page (throw Struts mapping). Individual actions can still be used
>with
>their associated components.
> Another approach is to say that individual <form> don't forward to the
>portal
>action, but to their own action which after that forward to the portal
>page, or
>to another page.
>
>It could be interesting to be able to associate an action (or something
>similar)
>to a component. But we have to take care to stay compliant with Struts
>philosophy, and to not overload what already exist. I have no elegant
>solution
>yet, but I keep the idea in mind. Any thought is welcome !
> In the meantime, don't forget that you can use the same Action class in
>different mapping, and that a mapping can forward to another Action !
>Also, you
>can put a scriplet calling your "action" at the beginning of a component
>(JSP
>page). It is also possible to create and use a bean in the component using
>standard jsp tag. This bean performs what you want in it constructor ...
>
> Cedric
>
>P.S.: Sorry for this late answer, I have miss your previous post.
>
>
>
>Rey Francois wrote:
>
>> I am reposting this item below because I haven't got any feedback since
>I
>> posted it on 8 March. Just briefly, this is about the ability to
>perform an
>> Action specific to a JSP component being reused. Right now it is not
>> possible to make an action being automatically performed when including
>a
>> JSP component.
>>
>> I'm sure some people would be able to comment (Craig and Cedric
>notably),
>> because I think the topic of reusing JSP components is (IMHO) an
>interesting
>> and essential one.
>>
>> Thanks in advance.
>>
>> François Rey
>> Financial WebSuite
>> The Capital Markets Company
>> http://www.capco.com/
>>
>> -----Original Message-----
>> From: Rey Francois [mailto:[EMAIL PROTECTED]]
>> Sent: 08 March 2001 14:40
>> To: '[EMAIL PROTECTED]'
>> Subject: JSP Components
>>
>> In the context of building reusable JSP components, I have been
>confronted
>> with the following limitation that both the Struts templating and the
>> Components from Cedric Dumoulin currently have.
>>
>> In a word, this limitation is actually due to the fact that none of them
>> provide a way to perform an action specific to the included JSP. For
>> example, an application home page may be composed of a body that
>actually
>> corresponds to another page in the web application. In this case, the
>body
>> is already modeled with a mapping and an action that performs the
>necessary
>> logic to retrieve the dynamic content. When servicing the home page, one
>> would logically like to reuse that action in order to avoid the
>duplication
>> of its logic in the action servicing the home page.
>>
>> One way to do this would be to directly call the action to reuse within
>the
>> perform() of the action servicing the home page. However this is not
>very
>> flexible because it requires manual intervention.
>>
>> My short research in past postings actually seems to indicate that this
>> problem has been mentioned before under various forms. A proposal for a
>> portal framework was discussed before, and such framework would require
>such
>> feature. In one instance the Jetspeed framework was considered for
>> integration with Struts. In another case one talked about allowing the
>> ActionServlet to do both forwards and includes.
>>
>> My questions then are:
>> - has anybody else been confronted to this limitation, and if so, did
>you
>> avoid the problem (for example by using frames) or did you find a
>solution?
>> - would such a feature be considered for inclusion in either Struts or
>the
>> Components framework from Cedric Dumoulin?
>> - anybody having further thoughts on this issue?
>>
>> Thanks for your feedback on this topic.
>>
>> François Rey
>> Financial WebSuite
>> The Capital Markets Company
>> http://www.capco.com/
>>
>> ************************************************************************
>> The information in this email is confidential and is intended solely
>> for the addressee(s).
>> Access to this email by anyone else is unauthorised. If you are not
>> an intended recipient, you must not read, use or disseminate the
>> information contained in the email.
>> Any views expressed in this message are those of the individual sender,
>> except where the sender specifically states them to be the views of
>> The Capital Markets Company.
>>
>> http://www.capco.com
>> ***********************************************************************
>>
>> ************************************************************************
>> The information in this email is confidential and is intended solely
>> for the addressee(s).
>> Access to this email by anyone else is unauthorised. If you are not
>> an intended recipient, you must not read, use or disseminate the
>> information contained in the email.
>> Any views expressed in this message are those of the individual sender,
>> except where the sender specifically states them to be the views of
>> The Capital Markets Company.
>>
>> http://www.capco.com
>> ***********************************************************************
>
Michael Oliver
Chief Architect
MorningStar Systems, Inc.
7391 S. Bullrider Ave.
Tucson, AZ 85747
520.574.1150 Voice
520.447.2736 Fax
443.277.0629 Mobile
Plaatsen ter Software Ontwikkeling
