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 00:15:30 GMT
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