Mailing-List: contact beehive-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <beehive-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of carlin.rogers@gmail.com
 designates 64.233.162.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=M0+5kNCn57G0v6fqJqLXlMowpcuuPHZynJs2oKi3wt9y5fTXznW4bW8xXiiWjTKzEGCJzoovEcGORVLijr8HHO3NPGbRM1rD8d78y0mej2THA85HNvhOlVR5KXcKa4P0Pnxkw39MKhXgPH7ItWgc0ssVe0C5ax6rhupYVtm2nGY=
Message-ID: <ba6911de050617080216c7f0d0@mail.gmail.com>
Date: Fri, 17 Jun 2005 09:02:08 -0600
From: Carlin Rogers <carlin.rogers@gmail.com>
Reply-To: Carlin Rogers <carlin.rogers@gmail.com>
To: beehive-dev@incubator.apache.org
Subject: URL Templating changes
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I have some changes I'd like to propose for the=20
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=20
parser to the URLTemplatesFactory and have a one time
call to the Factory to get the URLTemplates, I'd like=20
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.=20

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=20
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=20
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=20
the factory to use when verifying the templates (above).

At runtime, the actual URL formatting step in=20
URLRewriterService.getTemplatedURL() may also call ConfigUtils=20
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=20
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