You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Carlin Rogers <ca...@gmail.com> on 2006/03/04 08:55:06 UTC
Patch for beehive-1073 and changes to the nested page flow returns from a popup window feature...
All,
I've attached a patch that can be used to resolve the feature change request
in BEEHIVE-1073.
http://issues.apache.org/jira/browse/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 XHR
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
Re: Patch for beehive-1073 and changes to the nested page flow returns from a popup window feature...
Posted by Carlin Rogers <ca...@gmail.com>.
Daryl,
One question/concern I have about using the NameService. When we are at the
point of creating the new ActionForward and want to add the ViewRenderer to
the NameService, The only reference to the ViewRenderer is the
PageFlowRequestWrapper. In a framework (like a portal) or application that
uses a call to PageFlowUtils.strutsLookup(), we return a ActionResult and at
this point, I think the only reference to the ViewRenderer would be the weak
reference in the NameService. Wouldn't there be the potential that the
ViewRenderer could be garbage-collected before the XHR servlet gets the
forwarded request and tries to retrieve the INameable?
Thanks,
Carlin
On 3/4/06, Daryl Olander <do...@gmail.com> wrote:
>
> +1 for using the name service....
>
> On 3/4/06, Carlin Rogers <ca...@gmail.com> wrote:
> >
> > All,
> >
> > I've attached a patch that can be used to resolve the feature change
> > request
> > in BEEHIVE-1073.
> > http://issues.apache.org/jira/browse/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
> > XHR
> > 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
> >
> >
>
>
Re: Patch for beehive-1073 and changes to the nested page flow returns from a popup window feature...
Posted by Daryl Olander <do...@gmail.com>.
+1 for using the name service....
On 3/4/06, Carlin Rogers <ca...@gmail.com> wrote:
>
> All,
>
> I've attached a patch that can be used to resolve the feature change
> request
> in BEEHIVE-1073.
> http://issues.apache.org/jira/browse/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
> XHR
> 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
>
>