I'm not sure I follow all of this, but I may be understanding what you're trying to get at.

I'll guess at the steps using another donePage example in ecommerce (or the Party Manager):

1. user goes to viewprofile page
2. user clicks on link to edit a postal address, system takes them to edit address page 3. user edits the address, possibly with multiple form submissions to add/remove purposes and to edit address fields 4. user clicks on "done" or "return to xxx" or whatever, system takes them back to the viewprofile page knowing that is where they come from

The process is the same for various checkout and other pages which can be substituted in steps #1 and #4.

In general there is nothing special about the viewprofile page, but the edit address page needs special treatment because we go to it from different places and want to get back to where we came from.

In other words, when we go to the edit address page we want to somehow remember where we came from, and offer a link (or the result of some other action on the page) to go back to that page.

One possible solution is to:

A. set something on the edit address request that tells the RequestHandler to remember the previous request (or view to avoid redundant execution of an event... we would need to play with that in the context of different places this might be used); to make this more flexible and to allow keeping track of multiple saved user flow points we could make this a stack (or not, if that makes it too complex and confusing) B. provide ways to get back to the saved user flow points (saved requests): 1. build a URL for a link to get back to it (like our current "Done" links, which are kind of confusing and for cases where a screen needs multiple form submissions before the user goes back to the saved point it should say something other than "Done", ie something like "Return to Profile" 2. allow a request to forward the user back to the saved point, ie like the request-redirect except that instead of specifying the request you specify a token that represents the saved point (or pop most recent saved point from the stack and forward to it)

Is that about what you're trying to do?

-David


On Feb 18, 2009, at 7:34 AM, Hans Bakker wrote:

Hi David,

perhaps you can give me some advice/help especially now you reorganized the request handler and it still fresh in your mind? I want to get away
from the "donePage" stuff and i wonder if you can help me.

What i need is to display a portlet, let the portlet call a view which
in turn calls a service/event to update information and then it should
return to the portalpage which called the portlet.

This would allow portlets to be used in myportal and in the original
location.

I call the portlet within the showPortlet request, for example the
"party" portlet in the profile request in my portal with: (login as
admin)

https://demo.hotwaxmedia.com/myportal/control/showPortalPage?portalPageId=MYPORTAL_EMPLOYEE1&parentPortalPageId=MYPORTAL_EMPLOYEE

the 'update' button on the "Personal Information" portlet has at the
moment the following link:

https://demo.hotwaxmedia.com/myportal/control/editperson?partyId=admin

i modified it here with:
https://demo.hotwaxmedia.com/myportal/control/editperson/showPortalPage?partyId=admin&portalPage=MYPORTAL_EMPLOYEE1

because i want after the update to return to the showportal request.....

HOWEVER,

as you probably already know the editperson request calls a view, will
return with 'success' and the system will directly return to the
showportalpage view without showing the editperson view.

My question to you is: how can we change the request handler, so that
the editPerson menu is shown which will call a event or service to
update the database and when this returns with success, it  should
return to the view showPortalPage

in other words,
if the next request is a view, the requesthandler should show the first
view and carry the secondview to the next request.
Only if the next request is an event/service the requesthandler should
show the secondview if that service/event ended with success.

hopefully i explained clear enough....

Hans



Reply via email to