+1 for using the name service....
On 3/4/06, Carlin Rogers <[EMAIL PROTECTED]> 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 > >
