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
