Your forward config to another dispatch action should contain the
"method" parameter. For instance,
<forward name="edit"
path="/Configuration/Attributes/GoEditAttribute.do?method=edit"/>
<forward name="edit"
path="/Configuration/Attributes/GoEditAttribute.do?method=update"/>
I hope I interpreted your problem correctly.
On Mon, 14 Jun 2004 10:20:21 +0200, Cosyns Xavier <[EMAIL PROTECTED]> wrote:
>
> >I've used a similar approach but mine is working fine.
> >what does your struts-config.xml look like?
>
> Hi,
> Here is my struts-config, ShowAttributesList.do is my preaction before
> displayin the list of objects, then we select one of the list and
> execute the gocreateattribute action, and lastly we have the
> CreateAttribute action which will reforward to the ShowAttributesList on
> successful creation. The problem is that both actions are
> DispatchActions with the same parameter. As explained in my former mail
> I do not want to break that for different reasons.
>
> Is there something I am missing?
>
> <action
> path="/Configuration/Attributes/ShowAttributesList"
> name="objectTypeForm"
> scope="request"
> parameter="fxpAction"
> type="fxp.web.actions.configuration.attributes.AttributesLister"
> validate="false">
> <forward
> name="showList"
>
> path="/configuration/attributes/manageAttributesList.jsp"/>
> <forward
> name="edit"
>
> path="/Configuration/Attributes/GoEditAttribute.do"/>
> <forward
> name="delete"
>
> path="/Configuration/Attributes/GoDeleteAttribute.do"/>
> <forward
> name="create"
>
> path="/Configuration/Attributes/GoCreateAttribute.do"/>
> </action>
>
> <action
> path="/Configuration/Attributes/GoCreateAttribute"
> parameter="/configuration/attributes/createAttribute.jsp"
> input="/Configuration/Attributes/ShowAttributesList.do"
> name="objectTypeForm"
> scope="request"
> type="fxp.web.actions.configuration.attributes.GoCreateAttribute"
> validate="false" />
>
> <action
> path="/Configuration/Attributes/CreateAttribute"
> input="/configuration/attributes/createAttribute.jsp"
> name="createAttributeForm"
> scope="request"
> type="fxp.web.actions.configuration.attributes.CreateAttribute"
> parameter="fxpAction"
> validate="true">
> <forward
> name="showList"
>
> path="/Configuration/Attributes/ShowAttributesList.do"/>
> <forward
> name="create"
>
> path="/configuration/attributes/createAttribute.jsp"/>
> </action>
>
>
>
>
> >On Fri, 11 Jun 2004 11:26:54 +0200, Cosyns Xavier
> ><[EMAIL PROTECTED]> wrote:
> >>
> >> Hi,
> >>
> >> I run into problems with chaining dispatchactions using the same
> >> parameter 'method'. We do use the same parameter name for all our
> >> dispatchaction for consistency reasons throughout the whole
> >> application, easier to maintain and using generique javascript
> >> functions.
> >>
> >> The problem we ran into is that we have a first jsp page showing a
> >> list of items, and we achieve that by prepopulating with a
> >> dispatchaction some beans to be used in the jsp. Then we can go to a
> >> 'edit' page and when we submit we have another
> >dispatchaction with an
> >> 'update' method that should reforward on success to the first
> >> prepoplation dispatchaction. The problem is that forwarding
> >calls the
> >> 'update' method from the prepopulation dispatchaction, which
> >does not
> >> exist and should not exist. Redirecting the action does not
> >work as I
> >> lose a request parameter that permits to prepopulate the
> >right list of
> >> products on my first page (It will display the default list, not
> >> necesarely the list where he started an update upon).
> >>
> >> So, our action&page flow is the following:
> >> Prepopulation Action --> list.jsp --> detail (product Action) -->
> >> edit.jsp --> update (product action) --> Prepopulation Action.
> >>
> >> Only options I see,
> >> I could not use dispatchactions, but then I would have so many
> >> different action classes that are so closely related and
> >using common
> >> methods. I could break our 'inhouse rule' of using one global
> >> parameter name for dispatchactions, but it would not be
> >clean to have
> >> an exception to the rule, so I'm against that option. I could put an
> >> object in the session and in my prepopulation action testing for it,
> >> and if it exist showing the right list of products. But again, it's
> >> simulating a request parameter using a session, which is not a great
> >> design. None of the three options above are good design to me, so I
> >> would prefer another way.
> >>
> >> What I would need is more something like the 'unspecified'
> >method from
> >> dispatchactions that would also be called if the given
> >parameter does
> >> not match any of the methods of the dispatchaction. From my tests,
> >> it's not the case, the 'unspecified' method is called when the
> >> 'parameter' does not exist in the request and not when it does not
> >> match anny methods (my case). Or else, I would need a patameter
> >> 'overriding' mechanism, something where the dispatchaction
> >first do a
> >> request.getAttribute('method') and if this one does not
> >exist performs
> >> a request.getParameter('method'). But I have not found how
> >to achieve
> >> one of boths terchniques.
> >>
> >> I'm sure someone else ran into this issue too, and I am aware that
> >> chaining actions is not a recommended design, but it's not a
> >> bussinesslogic problem, the issues addressed here only concerns
> >> presentation. Or did I missed something?
> >>
> >> Thanks very much for your ideas,
> >>
> >> Cosyns Xavier,
> >> ______________________________
> >> [EMAIL PROTECTED]
> >>
> >> InveO Consulting & Development
> >> Av. E. de Beco 112
> >> 1050 Ixelles
> >> Tel: +32 2 648 74 32
> >> Fax: +32 2 648 87 64
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
