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 18:21:11 GMT
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