Hi..
Makes sense actually.. Not sure if we have to go so deep as to add new
configuration
fields. Maybe just extending one of the main controller modules..
ActionServlet, Action, ActionForward, ActionMapping etc.
Gotta look into that..
But one possible problem:
1. the user is on a page with a list of articles
2. user clicks view article
3. on the view article page he clicks edit
*now the edit page is a page which shows a form and it is used from
view article and list articles pages. So, the view article action puts
a ChainToPage object into the session so that after the form is
processed we now were we should return.
4. on the edit form there is a link back to the article list and the
user clicks that and doesn't submit the edit form (or the user
hits back - button a couple of times)
5. now on the article list page the user clicks edit straight from
one of the article titles or something.. Anyway he goes back to
the edit page and submits the form..
6. the user is back on the view article page and not the list articles page.
Am I totally lost here :)
/tuomo
2. User comes to the page which should read
Keith Bacon wrote:
>Hi Tuomo
>I'm about to work on that now. I'm thinking of setting
>up a ChainToPage class in the session. This would have
>properties
> // The global forwards to forward to
> String forwardTo
>
> // Name of Action this was set up for.
> String forUseBy
>
> // parms eg. selectedListItems,
> // selectedMultiBoxItem
> // sortSequece
> // position in Page to return to
> HashMap attributes
>A page can set up one of these objects & forward to a
>'slave' page - ie. a page that on completion forwards
>to the forwardTo page. This would then work for
>returning to an invoking page & also for chaining.
>
>Problems:-
>1 - People say using session doesn't scale. Personally
>I think it has to be made to! It's the logical place
>to save data - it's up to the servers to provide
>performance.
>2 - Junk gets left around by pgm errors or after
>exceptions. Careful hosekeeping needed. If only 1 such
>object can exist it's easier. Multiple levels of this
>would need some serious code.
>Keith.
>===============================
>PS. Some more:-
>Maybe struts could be enhanced to support this (not
>sure how yet!) but something like in config file
>for linkList action definition instead of the usual
>forward definition
>
><forward name="linkMaint" path="/linkMaint.do"/>
>
>have this
><forwardAndReturn name="linkMaint"
>path="/linkMaint.do"
>returnParms="mypackage.LinkListReturnParms"/>
>
><forwardAndReturn name="logon" path="/logon.do"
>returnParms="mypackage.LinkListReturnParms"/>
>
>ie. this page may forward to LinkMaint or to logon &
>those pages will return to linkList on completion.
>struts would pass mypackage.LinkListReturnParms to the
>linkList Action class which would fill them in. If the
>linklist uses forwardAndReturn struts will keep those
>parms in the session until linkList is re-invoked.
>Make sense?
>
>Keith
>
>
>
>
>
>
>
>
>--- Tuomo Syv�nper� <[EMAIL PROTECTED]>
>wrote:
>
>>In a way this is exactly what I do right now.. But
>>the problem is the
>>request attributes & parameters sent to the
>>'returnTo' page.. These are
>>lost when using this technique..
>>In my version I also set the request attributes as
>>hidden form fields
>>and pass them
>>on like that.. But I wasn't sure if it's a good idea
>>to pass them on as
>>hidden fields..
>>
>>/tuomo
>>
>>Keith Bacon wrote:
>>
>>>--- Keith Bacon <[EMAIL PROTECTED]> wrote:
>>>
>>>>Tuomo,
>>>>Not totally finalised but at the moment I do it a
>>>>bit
>>>>like the example below.
>>>>If you searched the archives for 'logon page'
>>>>
>>there
>>
>>>>are ways you can forward to the logon page & have
>>>>
>>it
>>
>>>>return to the page that started it, which is the
>>>>same
>>>>thing. These example are probably better than
>>>>
>>mine!
>>
>>>>Keith.
>>>>======
>>>>example - form1 transfers to form2 & wants form2
>>>>
>>to
>>
>>>>transfer to form1.
>>>>
>>>>
>>>>form1 has
>>>>/*
>>>>* Let next form know where to return to.
>>>>*/
>>>>request.addAttribute("returnTo",
>>>>"globalForwardForm1");
>>>>
>>>>
>>>>form2 has
>>>>/*----
>>>>1 - save the input returnTo value. 1st time in
>>>>caller
>>>>has stored it as req. attribute. Subsequent times
>>>>this
>>>>action has saved it as a hidden field on the form
>>>>(could save in the session).
>>>>------*/
>>>>String returnTo =
>>>>
>>request.getAttribute("returnTo");
>>
>>>>if (returnTo == null) formBean.getReturnTo();
>>>>
>>>>thisForm.setReturnTo() = returnTo;
>>>>
>>>>/*
>>>>* 2 - on completion
>>>>*/
>>>>return new ActionForward("returnTo");
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>--- Tuomo Syv�nper� <[EMAIL PROTECTED]>
>>>>wrote:
>>>>
>>>>>Hmm.. Nope. mapping.getInput() always returns the
>>>>>same thing regardless
>>>>>of the
>>>>>page from which we came from.
>>>>>Here's a bit more detailed explanation of what's
>>>>>going on:
>>>>>
>>>>>I have a page (action: listArticles.do) which
>>>>>
>>>>lists
>>>>
>>>>>all articles. On
>>>>>this page if you
>>>>>click on the edit - link,
>>>>>editArticle.do?action=Edit&id=123 action gets
>>>>>called.
>>>>>This action redirects the user to the
>>>>>editArticle.jsp page which has the
>>>>>edit form in it.
>>>>>Now if the user clicks on the title of the
>>>>>
>>article
>>
>>>>>on listArticles.do page,
>>>>>viewArticle.do?id=123 action gets called and
>>>>>
>>shows
>>
>>>>>the article. On this
>>>>>page we
>>>>>allso have an edit - link, which has the same url
>>>>>
>>>>as
>>>>
>>>>>the one on
>>>>>listArticles - page.
>>>>>
>>>>>The form submits its contents to saveArticle.do -
>>>>>action which does just
>>>>>that.. Saves
>>>>>the article using an EJB. After the save we
>>>>>
>>should
>>
>>>>>return to the calling
>>>>>page but at
>>>>>this point we no longer know which page was the
>>>>>original caller. And
>>>>>even if we did,
>>>>>we'd have no way of returning the request to the
>>>>>same state as it was
>>>>>before the
>>>>>editArticle - link was pressed (ie. the
>>>>>
>>>>viewArticle
>>>>
>>>>>had the article id
>>>>>as a parameter and
>>>>>if we forward control back to that viewArticle
>>>>>action, we really should
>>>>>have the id also).
>>>>>
>>>>>Now in saveArticle - action mapping.getInput()
>>>>>returns the
>>>>>editArticle.jsp form and
>>>>>not the page from which we came from..
>>>>>
>>>>>/tuomo
>>>>>
>>>>>Jon.Ridgway wrote:
>>>>>
>>>>>>Hi Tuomo,
>>>>>>
>>>>>>You could try using:
>>>>>>
>>>>>> mapping.getInput ()
>>>>>>
>>>>>>in your actions perform method.
>>>>>>
>>>>>>Jon.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Tuomo Syv�nper�
>>>>>>
>>>>>[mailto:[EMAIL PROTECTED]]
>>>>>
>>>>>>Sent: 12 December 2001 09:47
>>>>>>To: [EMAIL PROTECTED]
>>>>>>Subject: Alternate form action
>>>>>>
>>>>>>Hi,
>>>>>>How can I return to correct page after
>>>>>>
>>submitting
>>
>>>>a
>>>>
>>>>>form which can be
>>>>>
>>>>>>called from
>>>>>>several places..
>>>>>>What I have is a action&form which can be
>>>>>>
>>>>accessed
>>>>
>>>>>from many different
>>>>
>>>>>>places.
>>>>>>ie. I have page A with a link:
>>>>>><html:link page="/editArticle.do?action=Edit"
>>>>>>
>>>>>paramId="id"
>>>>>
>>>>>>paramName="article"
>>>>>>
>>>>>paramProperty="id"><bean:message
>>>>>
>>>>>>key="global.edit"/></html:link>
>>>>>>and page B with the same link. When the user
>>>>>>
>>>>posts
>>>>
>>>>>the form, I'd like to
>>>>>
>>>>>>return to
>>>>>>the page from which we came from.
>>>>>>Problem is that I cannot tell what possible
>>>>>>
>>>>request
>>>>
>>>>>parameters or
>>>>>
>>>>>>attributes the original
>>>>>>page had gotten before the call to editArticle.
>>>>>>
>=== message truncated ===
>
>
>__________________________________________________
>Do You Yahoo!?
>Check out Yahoo! Shopping and Yahoo! Auctions for all of
>your unique holiday gifts! Buy at http://shopping.yahoo.com
>or bid at http://auctions.yahoo.com
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
