beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryl Olander" <>
Subject Re: Patch for beehive-1073 and changes to the nested page flow returns from a popup window feature...
Date Sun, 05 Mar 2006 01:50:23 GMT
+1 for using the name service....

On 3/4/06, Carlin Rogers <> wrote:
> All,
> I've attached a patch that can be used to resolve the feature change
> request
> in BEEHIVE-1073.
> Some details about the design changes in this patch are below, followed by
> a
> couple of questions for the dev list.
> Now, when returning from a nested page flow popup window, after executing
> the action, an ActionForward is created to forward to a servlet rather
> that
> writing directly to the response. The forward path could have been to a
> new
> framework JSP, however, it was suggested that a servlet will allow us to
> extend this type of solution to other types of framework generated output.
> After calling the action, the code path continues through the
> DefaultActionForwardHandler.doAutoViewRender(). However, rather than
> writing
> to the response at this stage, it adds the ViewRenderer instance to the
> request as an attribute, constructs a URI mapped to the
> XmlHttpRequestServlet, and returns an ActionForward with this URI as the
> path. Then in the rendering phase when we process this new forward, the
> servlet gets the ViewRenderer object from the request attribute and writes
> the framework generated output (JavaScript) to the response.
> Following the design pattern of the XHR servlet, there's now a new request
> interceptor (ViewRendererCRI) that handles the forwarded request. It will
> check to see if the request has the desired extension, then get the
> ViewRenderer instance from the request and call its renderView() method.
> Other details...
> - By default, the URI in the forward is constructed with a ".render"
> extension for the servlet path. (E.g.
> "/returnActionViewRenderer.render?handler=_netui:ViewRenderer")
> - The web.xml file of the NetUI web-app that uses the nested page flow
> popup
> window feature will need to be updated to to include the serlvet mapping.
> (release notes)
>     <servlet-mapping>
>         <servlet-name>XmlHttpRequestServlet</servlet-name>
>         <url-pattern>*.render</url-pattern>
>     </servlet-mapping>
> A different extension mapping for this view rendering can also be
> configured
> via a <context-param> in the web.xml. Something like...
>     <context-param>
>         <param-name>ViewRenderingExtension</param-name>
>         <param-value>myExtension</param-value>
>     </context-param>
> and
>     <servlet-mapping>
>         <servlet-name>XmlHttpRequestServlet</servlet-name>
>         <url-pattern>*.myExtension</url-pattern>
>     </servlet-mapping>
> - The ViewRendererCRI has been added to the default
> beehive-netui-config.xml.
> However, any NetUI web-app that has a beehive-netui-config.xml and uses
> the
> nested page flow popup window feature will need to update this
> configuration
> file to include the new request interceptor.
>     <request-interceptor>
>         <interceptor-class>
>             org.apache.beehive.netui.tags.internal.ViewRendererCRI
>         </interceptor-class>
>     </request-interceptor>
> Other thoughts?
> This design definitely requires some configuration changes for anyone
> already using this feature in their web-app today. Any additional
> thoughts/concerns about handling these changes?
> Also, it was suggested that I use the NameService to store the
> ViewRenderer
> instance. It would implement Daryl's INameable interface and the name
> would
> be a param in the request. Then the ViewRendererCRI would use the name to
> retrieve the ViewRenderer instance from the NameService. This follows the
> same design as the other interceptors, TreeCRI and DivPanelCRI. I didn't
> use
> the NameService in this patch but if people feel it should be used for
> consistency or have some other thoughts, let me know and I'll add it in.
> Can
> be done easily.
> Kind regards,
> Carlin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message