Hi David, thanks for the answer. The way you describe it is exactly what i mean...portlets and their programs behind it should be completely independent of the component. They can be called from any place and have links which can be executed from the place the portlet is called.
so it should be possible to call it from any place and should return from the place it is called. This would really make the system very flexible. You know the requesthandler stuff a lot better than i do so if you can give me a hand here? Thanks very much in advance, regards, Hans On Fri, 2009-02-20 at 01:52 -0700, David E Jones wrote: > 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 > > > > > -- Antwebsystems.com: Quality OFBiz services for competitive rates
