beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: URL Templating changes
Date Wed, 22 Jun 2005 07:34:05 GMT
Sounds great, Carlin.  I'm guessing that the formatter will almost 
always be stateless, so I doubt that ensuring thread-safety will be a 
harsh requirement.

Rich

Carlin Rogers wrote:

>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 <richfeit@gmail.com> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>          
>>>>>
>>>      
>>>
>
>  
>

Mime
View raw message