Yes, I agree. I was also thinking that the URLTemplateDescriptor was looking an aweful lot like a wrapper that didn't do much other than have the URLTemplatesFactory object as member data. I think that URLTemplateDescriptor could go away and we'd just have the URLTemplatesFactory (as a top-level object as you pointed out) with the TemplatedURLFormatter. I like that they are both attributes on the ServletContext
I will also add some javadoc that the default TemplatedURLFormatter needs to be implemented in a thread-safe manner so the URLRewriterService can use the same instance from the context for multiple simultaneous requests. Thanks for the help. Carlin On 6/21/05, Rich Feit <[EMAIL PROTECTED]> wrote: > Would it make sense for the TemplatedURLFormatter (seems like the > top-level thing) to live in the ServletContext? > > And (taking the collapsing further), could it be that we'd have only two > top-level objects: the TemplatedURLFormatter and the URLTemplatesFactory > (or URLTemplateFactory)? > > Rich > > Carlin Rogers wrote: > > > One other thought on this... > > > > To avoid adding code with knowledge of ConfigUtils and > > beehive-netui-config.xml into the URLRewriterService, I > > think the per-webapp, TemplatedURLFormatter should also > > be available from the ServletContext. > > > > So, whatever object is put as an attribute of the context, > > we should be able to get a template (via the factory) > > and the class name of a TemplatedURLFormatter. > > > > Just wanted to mention this in case it had impact on decisions > > about collapsing classes together and the functions of > > the object we set as an attribute of the context. > > > > Carlin > > > > Carlin Rogers wrote: > > > >> Hi Rich, > >> > >> Thanks for the feedback. Yes, your summary below is mostly > >> accurate. One comment... > >> > >> > URLTemplates: a set of URLTemplates. URLTemplateDescriptor > >> > keeps a single copy of this. > >> > >> Yes, at the moment. However, the proposed change is for the > >> URLTemplatesFactory to always return a URLTemplate and that > >> URLTemplateDescriptor would not have a copy of URLTemplates. > >> That way, a container-specific factory implementation > >> could support features like runtime reload of the file > >> if required. > >> > >> So, your observation about combining makes some sense. There's > >> no real need for the URLTemplates object if the > >> URLTemplateDescriptor no longer hangs onto a URLTemplates, > >> just goes to the URLTemplatesFactory. > >> > >> The URLTemplateDescriptor would be the object set as the > >> attribute of the context. > >> > >> Maybe there is more room for collapsing the classes together. > >> > >> Thanks, > >> Carlin > >> > >> > >> Rich Feit wrote: > >> > >>> Hi Carlin, > >>> > >>> This sounds good to me, but first I'd just like to clarify all the > >>> moving pieces here. This is what I (think I) understand: > >>> > >>> TemplatedURLFormatter: the code that is called by URLRewriterService > >>> to apply any relevant templates to a URL, after all other rewriting > >>> has been done on the URL. There is a default implementation of > >>> this, and it can also be overridden in one of two ways: > >>> 1) per-webapp, in beehive-netui-config.xml (with a class name) > >>> 2) per-request, if during a particular request, a certain > >>> implementation should be used. > >>> > >>> URLTemplateDescriptor: a single webapp-scoped instance that the > >>> TemplatedURLFormatter uses to look up URL templates. > >>> > >>> URLTemplate: a single URL template that can be applied to a URL. > >>> > >>> URLTemplates: a set of URLTemplates. URLTemplateDescriptor keeps a > >>> single copy of this. > >>> > >>> URLTemplatesFactory: the factory that provides the URLTemplates to > >>> URLTemplateDescriptor. There is a default implementation, but it > >>> can be overridden per-container through ServletContainerAdapter. > >>> This would allow a container-specific implementation to read from > >>> something other than the standard XML file. > >>> > >>> First, is that correct? Second, it looks like URLTemplateDescriptor > >>> and URLTemplates could be combined (i.e., there could be a single > >>> URLTemplates object kept in the ServletContext, in place of > >>> URLTemplateDescriptor. Would this make sense, or should there > >>> really be some distinction between the two? > >>> > >>> Thanks, > >>> Rich > >>> > >>> Carlin Rogers wrote: > >>> > >>>> 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 > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > >
