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
