You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tiles.apache.org by Oleg Gorobets <ol...@gmail.com> on 2008/02/05 14:45:31 UTC
Attribute-level extension point
Hi all!
Let's discuss providing an extension point for
BasicTilesContainer.render(Attribute, Writer, Object... requestItems). Much
like preparer acts for AttributeContext it will be useful to have such
ability for each concrete attribute. For instance, it will help to handle
the hierarchy of attributes and use tiles as layout for portal pages (e.g.
tracking portlet window id).
Corresponding JIRA issue:
<https://issues.apache.org/struts/browse/TILES-247>
https://issues.apache.org/struts/browse/TILES-247
Any comments/suggestions are welcome.
Sincerely,
Oleg Gorobets
Re: Attribute-level extension point
Posted by Antonio Petrelli <an...@gmail.com>.
2008/2/6, Oleg Gorobets <ol...@gmail.com>:
> I guess we can start without "attribute type" and simply implement the
> configurable renderer, which receive a String (defining the value of
> attribute) and current attribute context.
+1. Notice that the attribute value is an Object, though it is a
string most of the time.
> Later it can be extended with the attribute type.
At this point the concept of "attribute type" can be dropped, in
favour of the attribute renderer: in fact, the attribute type is used
only to render it correctly.
> I'll try to help with this, but I'm not so familiar with
> the existing design... I'll look into it if I find with the solution I'll
> share it with you.
Thanks :-) Feel free to attach your (eventual) work in TILES-190 or in
TILES-247, dependending on where it is appropriate.
Ciao
Antonio
RE: Attribute-level extension point
Posted by Oleg Gorobets <ol...@gmail.com>.
>
> +1 for the "unnecessary" definitions, but I think that the problem is only
> in the tiles-defs.xml file.
> What I mean is that we can still use the Definition class to describe an
> attribute with a preparer. The difference is that an "anonymous"
> definition
> is created whenever an attribute with a preparer is defined in the XML
> file.
> For example:
>
> <definition name="mydef" template="/mytemplate.jsp">
> <put-attribute name="attrib1" value="/firstTile.jsp"/ > <!-- Creates an
> Attribute of "template" value -->
> <put-attribute name="attrib1" value="/secondTile.jsp" preparer="
> my.package.MyPreparer" /> <!--Creates an attribute of "definition" value,
> a
> new "anonymous" definition with the secondTile.jsp as a template and the
> defined preparer. -->
> </definition>
Hmm.. that's interesting, I'll try it, but this solution is not going to
solve the problem of defining preparer in each attribute. We need a way to
define preparer system-wide to make design more elegant. So I think we
definitely need to look inside TILES-190 and try to implement a "renderer"
concept.
> The second one is a higher abstraction which can be named "attribute
> > renderer" (as stated in TILES-190). This will allow fully customized
> > rendering.
>
>
>
> In fact I was thinking of a "default renderer" dependent on the attribute
> type, and a custom renderer for the particular attribute.
> This solution needs a good design though. Anyone is willing to do a Class
> Diagram? :-)
>
I guess we can start without "attribute type" and simply implement the
configurable renderer, which receive a String (defining the value of
attribute) and current attribute context. Later it can be extended with the
attribute type. I'll try to help with this, but I'm not so familiar with
the existing design... I'll look into it if I find with the solution I'll
share it with you.
Re: Attribute-level extension point
Posted by Antonio Petrelli <an...@gmail.com>.
2008/2/5, Oleg Gorobets <ol...@gmail.com>:
>
> Sure, I can use a new definition/preparer for each attribute but that's a
> little bit clumsy I guess. If I need to "prepare" every attribute there
> will
> be a lot of unnecessary definitions.
+1 for the "unnecessary" definitions, but I think that the problem is only
in the tiles-defs.xml file.
What I mean is that we can still use the Definition class to describe an
attribute with a preparer. The difference is that an "anonymous" definition
is created whenever an attribute with a preparer is defined in the XML file.
For example:
<definition name="mydef" template="/mytemplate.jsp">
<put-attribute name="attrib1" value="/firstTile.jsp"/ > <!-- Creates an
Attribute of "template" value -->
<put-attribute name="attrib1" value="/secondTile.jsp" preparer="
my.package.MyPreparer" /> <!--Creates an attribute of "definition" value, a
new "anonymous" definition with the secondTile.jsp as a template and the
defined preparer. -->
</definition>
The second one is a higher abstraction which can be named "attribute
> renderer" (as stated in TILES-190). This will allow fully customized
> rendering.
In fact I was thinking of a "default renderer" dependent on the attribute
type, and a custom renderer for the particular attribute.
This solution needs a good design though. Anyone is willing to do a Class
Diagram? :-)
Antonio
RE: Attribute-level extension point
Posted by Oleg Gorobets <ol...@gmail.com>.
> -----Original Message-----
> From: Antonio Petrelli [mailto:antonio.petrelli@gmail.com]
> Sent: Tuesday, February 05, 2008 4:14 PM
> To: dev@tiles.apache.org
> Subject: Re: Attribute-level extension point
>
> 2008/2/5, Oleg Gorobets <ol...@gmail.com>:
> >
> > Let's discuss providing an extension point for
> > BasicTilesContainer.render(Attribute, Writer, Object... requestItems).
> > Much
> > like preparer acts for AttributeContext it will be useful to have such
> > ability for each concrete attribute.
>
>
> In fact you can use a definition as a value for an attribute, and put a
> preparer in this definition: does not it suffice for you?
>
Sure, I can use a new definition/preparer for each attribute but that's a
little bit clumsy I guess. If I need to "prepare" every attribute there will
be a lot of unnecessary definitions.
I can suggest 2 solutions: the first is a simple one: define an
AttributePreparer much like ViewPreparer and call it whenever the rendering
phase starts, e.g. from BasicTilesContainer.render().
The second one is a higher abstraction which can be named "attribute
renderer" (as stated in TILES-190). This will allow fully customized
rendering.
Re: Attribute-level extension point
Posted by Antonio Petrelli <an...@gmail.com>.
2008/2/5, Oleg Gorobets <ol...@gmail.com>:
>
> Let's discuss providing an extension point for
> BasicTilesContainer.render(Attribute, Writer, Object... requestItems).
> Much
> like preparer acts for AttributeContext it will be useful to have such
> ability for each concrete attribute.
In fact you can use a definition as a value for an attribute, and put a
preparer in this definition: does not it suffice for you?
For instance, it will help to handle
> the hierarchy of attributes and use tiles as layout for portal pages (e.g.
> tracking portlet window id).
Please elaborate it, with a concrete example.
Thanks
Antonio
RE: Attribute-level extension point
Posted by Oleg Gorobets <ol...@gmail.com>.
I guess it is somehow related to 'attribute renderer' as stated in TILES-190
(subtask of TILES-188).
> -----Original Message-----
> From: Pawel Kozlowski [mailto:pawel.kozlowski@gmail.com]
> Sent: Tuesday, February 05, 2008 3:53 PM
> To: dev@tiles.apache.org
> Subject: Re: Attribute-level extension point
>
> Hi,
>
> On Feb 5, 2008 2:45 PM, Oleg Gorobets <ol...@gmail.com> wrote:
> > Hi all!
> > Let's discuss providing an extension point for
> > BasicTilesContainer.render(Attribute, Writer, Object... requestItems).
> Much
> > like preparer acts for AttributeContext it will be useful to have such
> > ability for each concrete attribute. For instance, it will help to
> handle
> > the hierarchy of attributes and use tiles as layout for portal pages
> (e.g.
> > tracking portlet window id).
>
> Isn't it the same as TILES-188?
> (https://issues.apache.org/struts/browse/TILES-188)
>
> Cheers,
> Pawel
Re: Attribute-level extension point
Posted by Pawel Kozlowski <pa...@gmail.com>.
Hi,
On Feb 5, 2008 2:45 PM, Oleg Gorobets <ol...@gmail.com> wrote:
> Hi all!
> Let's discuss providing an extension point for
> BasicTilesContainer.render(Attribute, Writer, Object... requestItems). Much
> like preparer acts for AttributeContext it will be useful to have such
> ability for each concrete attribute. For instance, it will help to handle
> the hierarchy of attributes and use tiles as layout for portal pages (e.g.
> tracking portlet window id).
Isn't it the same as TILES-188?
(https://issues.apache.org/struts/browse/TILES-188)
Cheers,
Pawel