Some advise David about requests and portlets?

[Hans Bakker]

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

[David E Jones-3]

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
>
>

[hans_bakker]

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

[Adrian Crum]

David E Jones wrote:
>    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)

I like this idea! Maybe put a URL Stack in the session attributes.

-Adrian