beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlin Rogers <crog...@bea.com>
Subject Re: URL Templating changes
Date Mon, 20 Jun 2005 19:01:51 GMT
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