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 <[EMAIL PROTECTED]> wrote: > > +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 > > > > > >
