[tiles3] More subprojects to achieve "universality"

[Antonio Petrelli <an...@gmail.com>]

Hi all
During this holiday, sometimes I had time to think about Tiles 3 (when
you leave your mind wandering around, usually some ideas come out...).
I think that Tiles can have more "spin offs", besides tiles-request
and autotag. In particular:

1. Universal render
If you take a look at AttributeRender, you will notice that, under the
same interface, we uniformed the rendering of a path independently to
the particular technology.
Yes, AttributeRenderer.render wants an attribute, but currently every
written implementations uses a string, i.e. a path (even
DefinitionAttributeRender renders a path, i.e. the definition name).

2. Universal expression evaluation
In this case, the main interface is AttributeEvaluator, but even in
this case we have a single interface and only string expressions are
evaluated (not complete attributes). In this case, the situation is a
bit explicit, because we have two "evaluate" methods (one for
Attribute, one for String), but the AbstractAttributeEvaluator class
(that is the base class of any currently written implementation)
redirects the attribute evaluation to the other method.

If we could extract these capabilities to separate projects, they
would be useful even for non Tiles users.

WDYT?

Antonio

Re: [tiles3] More subprojects to achieve "universality"

[Antonio Petrelli <an...@gmail.com>]

2010/8/29 Nathan Bubna <nb...@gmail.com>:
> Sounds reasonable.  I'm not all that familiar with the details of the
> code you describe, so it's hard for me to comment intelligently, but i
> trust your judgment.

I hope to be clearer with an example for AttributeRenderer, near to
your experience with Velocity ;-)

TemplateAttributeRenderer renders a template using the normal
RequestDispatcher. This is useful for all templates that can be
invoked through a servlet (e.g. JSP pages).

VelocityAttributeRenderer does not use a servlet explicitly, but uses
a private instance of VelocityView that is invoked this way:

<snip>
ServletRequest servletRequest = ServletUtil.getServletRequest(request);
// then get a context
Context context = velocityView.createContext(servletRequest
        .getRequest(), servletRequest.getResponse());

// get the template
Template template = velocityView.getTemplate((String) value);

// merge the template and context into the writer
velocityView.merge(template, context, request.getWriter());
</snip>

A similar implementation is for Freemarker, but uses a private
instance of a servlet class.

In all of these cases, the invocation is made through the render environment:

<snip>
void render(Attribute attribute, Request request) throws IOException;
</snip>

A similar approach is applied for evaluators.

Thanks for the feedback
Antonio

Re: [tiles3] More subprojects to achieve "universality"

[Nathan Bubna <nb...@gmail.com>]

Sounds reasonable.  I'm not all that familiar with the details of the
code you describe, so it's hard for me to comment intelligently, but i
trust your judgment.

On Sat, Aug 28, 2010 at 10:45 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> Hi all
> During this holiday, sometimes I had time to think about Tiles 3 (when
> you leave your mind wandering around, usually some ideas come out...).
> I think that Tiles can have more "spin offs", besides tiles-request
> and autotag. In particular:
>
> 1. Universal render
> If you take a look at AttributeRender, you will notice that, under the
> same interface, we uniformed the rendering of a path independently to
> the particular technology.
> Yes, AttributeRenderer.render wants an attribute, but currently every
> written implementations uses a string, i.e. a path (even
> DefinitionAttributeRender renders a path, i.e. the definition name).
>
> 2. Universal expression evaluation
> In this case, the main interface is AttributeEvaluator, but even in
> this case we have a single interface and only string expressions are
> evaluated (not complete attributes). In this case, the situation is a
> bit explicit, because we have two "evaluate" methods (one for
> Attribute, one for String), but the AbstractAttributeEvaluator class
> (that is the base class of any currently written implementation)
> redirects the attribute evaluation to the other method.
>
> If we could extract these capabilities to separate projects, they
> would be useful even for non Tiles users.
>
> WDYT?
>
> Antonio
>