[Tapestry Wiki] Update of "PortletSupport" by NickWestgate

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tapestry Wiki" for change notification.

The following page has been changed by NickWestgate:
http://wiki.apache.org/tapestry/PortletSupport

------------------------------------------------------------------------------
  second page and set render parameters to point to that new page.
  
  There's no push to make Portlet Tapestry URLs pretty!  The portlet URLs are already hideous and nobody cares ... and you don't tend to bookmark portlets (do you?).
+ 
  ----
- A couple of notes:
+ DavidDeWolf: 
   * I'm not following the connection between the request type and portlet mode.  I think they are much more independent than you may think.
   * Typically a change in the PortletMode is used to alert the portlet that the user has requested alternative content.  Because the portlet container maintains the state of a portlet when it switches modes, many portlets provide context sensitive help pages.  To enable this type of functionality, a simple one to one mapping of modes to pages may not be enough.
+ 
+ HowardLewisShip: If the user clicks the "help" button, then the action request will be for portlet mode "help".  In the absence of any additional parameters, Tapestry should activate the 
+ porlet's Help page.  One you are on the help page, there may be additional links that activate other pages, say page "MoreHelp".  The page service will create additional render parameters (service=page, page=MoreHelp) ... these will be available during subsequent render requests to get the MoreHelp page rendered.
+ 
+ I do see what you mean about context sensitive help (or editting).  That's why I think there will be a service, "help", that will be invoked (in the absence of a service render parameter). The default implementation can activate the Help page, an application-specific implementaton could do something smarter.  But you raise an interesting question ... I need to investigate what kind of information is available during a help action request (or any other mode for that matter) ... and I think the portlet will need to track an "active page" in the session.
  
  
  == PLT.5.2.4.4 (page 27) ==
@@ -75, +81 @@

  stores the customer id and is stored into a persistent page property.  CustomerSummary gets activated, so a render URL properties are set: service=page, page=CustomerSummary.
  
  ----
- Some more notes:
+ DavidDeWolf: 
   * One thing to be aware of about action and request urls is that portlet specification does not require the container to maintain request attributes between the two request types.  Because many containers implement the transition from an action request to a render request as a redirect, attributes bound to the ActionRequest will not be available for rendering.  For clarity on this, see the Portlet1.0 Errata http://www.jcp.org/aboutJava/communityprocess/final/jsr168/Portlet_Specification_Errata.html#issue10
+ 
+ HowardLewisShip: I am aware of this, so my design is only going to rely on the action request setting render parameters, not attributes. These will be used for any subsequent renders before
+ the next action request. Beyond that, we'll use portlet context attributes (equivalent to !HttpSession attributes).
  
  == PLT.7.1.1 (page 32) ==
  
@@ -105, +114 @@

  I was about to say ... ''ideally, we'll have the technology in place to encode persistent properties as query parameters in 3.1.'' However, that really isn't an issue ... whether it's PortletSession attributes or query parameters inside the render URL, it's still server side state.  I wonder how portlet containers deal with browser back button and redirect-after-post issues?
  
  ----
+ DavidDeWolf: 
   * Because of the clear seperation between the action request and the render request, portlet-container's themselves typically use a redirect after post to transition from the action request to the render request.
+ 
+ HowardLewisShip: That's good to know.  I need to write more experiments.
  
  == PLT.11.1.8 (page 46) ==
  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org