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 ErikVullings: 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: + * 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. + == PLT.5.2.4.4 (page 27) == @@ -68, +73 @@ Thier "show customer summary" example could cut either way. To me, the Tapestry equivalent would be service=external, page=CustomerSummary, sp=Sfoo.com. The service parameter (sp) 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: + * 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 == PLT.7.1.1 (page 32) == @@ -95, +104 @@ 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? + ---- + * 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. + == PLT.11.1.8 (page 46) == The portlet container is responsible for localization; this bypasses the standard Tapestry issue with a page changing locale, and then rendering in the old locale. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
