URL Templating changes

[Carlin Rogers <ca...@gmail.com>]

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

Re: URL Templating changes

[Rich Feit <ri...@gmail.com>]

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 <ri...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>          
>>>>>
>>>      
>>>
>
>  
>

Re: URL Templating changes

[Carlin Rogers <ca...@gmail.com>]

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 <ri...@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
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
>

Re: URL Templating changes

[Rich Feit <ri...@gmail.com>]

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
>>>>
>>>>  
>>>>
>>>
>>>
>>
>
>

Re: URL Templating changes

[Carlin Rogers <cr...@bea.com>]

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
>>>
>>>  
>>>
>>
>>
> 

Re: URL Templating changes

[Carlin Rogers <cr...@bea.com>]

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
>>
>>  
>>
> 
> 

Re: URL Templating changes

[Rich Feit <ri...@gmail.com>]

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
>
>  
>