I have some changes I'd like to propose for the beehive-url-template-config.xml support and the use of a default TemplatedURLFormatter class. I'm interested in providing a hook for container specific ways to read/load the URL templates config file and web app specific default formatting behavior.
When loading the templates at start up time, a container specific URLTemplatesFactory could handle reading/parsing the template config file. This could allow for support of deployment plans, etc. Rather than have the URLTemplateDescriptor pass a parser to the URLTemplatesFactory and have a one time call to the Factory to get the URLTemplates, I'd like the factory itself be passed to the URLTemplateDescriptor and always be called for the templates. The factory really is what manages/returns the URLTemplates. The ServletContainerAdapter interface would have a method to get the container specific URLTemplatesFactory. During the Servlet.init() process we would get the factory and pass it into the URLTemplatesFactory. To support the various ways a factory may manage the templates, we should make URLTemplates an abstract class, with abstract methods getTemplate() and getTemplateNameByRef(). The Factory implementation may want to verify the set of known and required tokens for the templates. I feel that a default app specific TemplatedURLFormatter should contain the collection of tokens. This collection would be passed to the factory first so the factory could use them to verify templates. It would be nice if the application could define the default TemplatedURLFormatter rather than always fall back into the NetUI implementation and the known/req. tokens we have. An application or even a container (portal) may have additional tokens for the same page flow templates, something that our default NetUI formatter may not know how to handle. A different default formatter could be declared in the config file, beehive-netui-config.xml. We would then use ConfigUtils to check for and get the default formatter. If one is not defined, then we would use our NetUI implementation. We can then get the known and required tokens from this object for the factory to use when verifying the templates (above). At runtime, the actual URL formatting step in URLRewriterService.getTemplatedURL() may also call ConfigUtils to get the default TemplatedURLFormatter as needed. First getTemplatedURL() will see if a TemplatedURLFormatter was registered for the given request and use it. If there is no registered request, then we will see if there is a app specific default formatter from ConfigUtils. Finally, if we still have no formatter, then we will use the NetUI implementation of TemplatedURLFormatter. Since these formatters need to get the desired templates from the URLTemplateDescriptor (in turn, the factory of the template descriptor), At load time, the URLTemplateDescriptor can be set on the ServletContext. Then the context will have a reference to this object to ensure it remains available. A runtime call to URLRewriterService.getTemplatedURL() will include the ServletContext so any given formatter can get the template descriptor object and request the desired template. Summary of changes... Start Up: - get a URLTemplatesFactory from the container adapter. - get a default TemplatedURLFormatter from the config. - get known/req tokens from default TemplatedURLFormatter and pass to factory. - pass factory to the URLTemplateDescriptor. - load the templates URLTemplateDescriptor/URLTemplatesFactory. - set the URLTemplateDescriptor on the ServletContext. Runtime: - Check for TemplatedURLFormatter for the request, then - check for default TemplatedURLFormatter from the config, then - use the NetUI default TemplatedURLFormatter. Let me know what you think. Thanks, Carlin
