You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Cedric Dumoulin <ce...@lifl.fr> on 2006/10/05 15:45:14 UTC
[tiles2] Some words about proposed changes
Hi all,
I just came across some of the mails about Tiles2. First, I am very
glad that someone has the time to let Tiles evolve.
But, I am a little bit disappointed about how the proposed Tiles API
evolved.
In some case, I have the feeling that we are going backward :-).
A lot of redundancy in Tiles comes because of the backward
compatibility with the template library. Some new tag names where
proposed because old ones were confusing. In the same time, the old
names were left for backward compatibility.
If I remember well :
* <get> was changed to <insert> - because we mainly say that we want
to insert something
* Attributes "template=" and "component=" were changed to "page=" -
because we specify the page to insert. Tiles is more than a
templating mechanism, and the inserted page is not necessary a
template :-). Maybe we can use "tile=" now that tile is a very
well established name.
* The controllers were added to allows stand alone use of tiles to
be able to do some kind of computation associated to the tiles.
When used with Struts, there is a redundancy (with the use of
actions), but when used alone, the controller mechanism is very
useful to separate view rendering from controller business
It is true that Tiles2 gives us the opportunity to remove all the
redundancies, but we have to take care to not fall again into the
previous mistakes :-)
Once again, that my feeling after reading some of the mails, and maybe I
have missed something in the discussions.
Cedric
Antonio Petrelli wrote:
> Re-hi list :-)
>
> I noticed that GetTag extends InsertTag and it does not add anything,
> it only sets "isErrorIgnored" flag to true.
> So I am thinking on removing one of those.
> From my POV it should be better to remove InsertTag (or better, remove
> GetTag then rename InsertTag to GetTag), because this way it is clear
> that GetTag is the opposite of PutTag.
> What do you think?
>
> Ciao
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [tiles2] Some words about proposed changes
Posted by Craig McClanahan <cr...@apache.org>.
On 10/5/06, Nathan Bubna <nb...@gmail.com> wrote:
>
> I think "controllers" should stay, but the name should be changed.
> Call them ViewPreparers or something...
I would agree. The useful thing you can do here is prepare the data needed
to do the subsquent rendering. It is called *after* the controller has
already dispatched and chosen which view to render.
Craig
On 10/5/06, Greg Reddin <gr...@apache.org> wrote:
> >
> > On Oct 5, 2006, at 9:53 AM, Antonio Petrelli wrote:
> >
> > >> * The controllers were added to allows stand alone use of tiles to
> > >> be able to do some kind of computation associated to the tiles.
> > >> When used with Struts, there is a redundancy (with the use of
> > >> actions), but when used alone, the controller mechanism is very
> > >> useful to separate view rendering from controller business
> > >
> > > The problem with Tiles controllers is that the controller is not
> > > able to
> > > choose between different destination pages. It misses an important
> > > part
> > > of a controller: the dispatcher.
> > > But using a normal url as a template (or tile :-) ) it can do both
> > > calling the model and dispatching. If you download the latest version
> > > from SVN, there is a test with a simple servlet that includes a (fixed
> > > for the moment) JSP page.
> > > And I think that including a Controller in a View layer technology is
> > > not a good idea.
> >
> > Here's what I envision for the controller: I don't think it would
> > really be used to change the destination of the response. I don't
> > see the controller as being analogous to a Struts action even though
> > it could be used in that way. If I wanted the controller to be used
> > as a "controller" in the MVC sense of the word (IOW to select a
> > destination) I'd want it to return something like actions do in
> > Struts, WebWork, and JSF. I've always used the controller like a JSP
> > tag. I use it to implement code that needs to reside in the view
> > layer (or code that needs to be called from the view layer) and as a
> > way to keep from writing scriptlet code in my JSPs.
> >
> > It just so happens that the controller API gives you indirect access
> > to the request and response objects so you could use them to include
> > or forward or write directly to the response and all the other stuff
> > you can do there. But I'd not recommend the controller be used in
> > this way. I would use the controller to manipulate the TilesContext
> > and the JSP contexts, but not to actually "do anything" with regards
> > to changing the destination.
> >
> > In today's world if I was writing a Struts app with Tiles I would try
> > to use JSTL, EL, custom tags, (or in JSF, action listeners, etc). to
> > do things I did in the past with controllers. But I can still see
> > circumstances where I might want a controller instead.
> >
> > Think about this: Tiles can be used for page composition outside of
> > any MVC framework. In that sense it's kind of like a portlet
> > container. (In fact I think that's how Cedric envisioned it before
> > JSR-168 came about). So you can compose pages out of JSP fragments
> > and populate each fragment with a controller that is executed before
> > the fragment is processed and included. I actually have written a
> > couple of small webapps that use Tiles in this way and see it as a
> > powerful feature.
> >
> > I think we should retain the controller for Tiles definitions (not
> > sure about the insert tag). I also think we should document the fact
> > that you can get yourself into all kinds of trouble by making
> > improper use of the request and response APIs from within the
> > controller.
> >
> > Thoughts?
> > Greg
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [tiles2] Some words about proposed changes
Posted by Nathan Bubna <nb...@gmail.com>.
I think "controllers" should stay, but the name should be changed.
Call them ViewPreparers or something...
On 10/5/06, Greg Reddin <gr...@apache.org> wrote:
>
> On Oct 5, 2006, at 9:53 AM, Antonio Petrelli wrote:
>
> >> * The controllers were added to allows stand alone use of tiles to
> >> be able to do some kind of computation associated to the tiles.
> >> When used with Struts, there is a redundancy (with the use of
> >> actions), but when used alone, the controller mechanism is very
> >> useful to separate view rendering from controller business
> >
> > The problem with Tiles controllers is that the controller is not
> > able to
> > choose between different destination pages. It misses an important
> > part
> > of a controller: the dispatcher.
> > But using a normal url as a template (or tile :-) ) it can do both
> > calling the model and dispatching. If you download the latest version
> > from SVN, there is a test with a simple servlet that includes a (fixed
> > for the moment) JSP page.
> > And I think that including a Controller in a View layer technology is
> > not a good idea.
>
> Here's what I envision for the controller: I don't think it would
> really be used to change the destination of the response. I don't
> see the controller as being analogous to a Struts action even though
> it could be used in that way. If I wanted the controller to be used
> as a "controller" in the MVC sense of the word (IOW to select a
> destination) I'd want it to return something like actions do in
> Struts, WebWork, and JSF. I've always used the controller like a JSP
> tag. I use it to implement code that needs to reside in the view
> layer (or code that needs to be called from the view layer) and as a
> way to keep from writing scriptlet code in my JSPs.
>
> It just so happens that the controller API gives you indirect access
> to the request and response objects so you could use them to include
> or forward or write directly to the response and all the other stuff
> you can do there. But I'd not recommend the controller be used in
> this way. I would use the controller to manipulate the TilesContext
> and the JSP contexts, but not to actually "do anything" with regards
> to changing the destination.
>
> In today's world if I was writing a Struts app with Tiles I would try
> to use JSTL, EL, custom tags, (or in JSF, action listeners, etc). to
> do things I did in the past with controllers. But I can still see
> circumstances where I might want a controller instead.
>
> Think about this: Tiles can be used for page composition outside of
> any MVC framework. In that sense it's kind of like a portlet
> container. (In fact I think that's how Cedric envisioned it before
> JSR-168 came about). So you can compose pages out of JSP fragments
> and populate each fragment with a controller that is executed before
> the fragment is processed and included. I actually have written a
> couple of small webapps that use Tiles in this way and see it as a
> powerful feature.
>
> I think we should retain the controller for Tiles definitions (not
> sure about the insert tag). I also think we should document the fact
> that you can get yourself into all kinds of trouble by making
> improper use of the request and response APIs from within the
> controller.
>
> Thoughts?
> Greg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Some words about proposed changes
Posted by Greg Reddin <gr...@apache.org>.
On Oct 5, 2006, at 9:53 AM, Antonio Petrelli wrote:
>> * The controllers were added to allows stand alone use of tiles to
>> be able to do some kind of computation associated to the tiles.
>> When used with Struts, there is a redundancy (with the use of
>> actions), but when used alone, the controller mechanism is very
>> useful to separate view rendering from controller business
>
> The problem with Tiles controllers is that the controller is not
> able to
> choose between different destination pages. It misses an important
> part
> of a controller: the dispatcher.
> But using a normal url as a template (or tile :-) ) it can do both
> calling the model and dispatching. If you download the latest version
> from SVN, there is a test with a simple servlet that includes a (fixed
> for the moment) JSP page.
> And I think that including a Controller in a View layer technology is
> not a good idea.
Here's what I envision for the controller: I don't think it would
really be used to change the destination of the response. I don't
see the controller as being analogous to a Struts action even though
it could be used in that way. If I wanted the controller to be used
as a "controller" in the MVC sense of the word (IOW to select a
destination) I'd want it to return something like actions do in
Struts, WebWork, and JSF. I've always used the controller like a JSP
tag. I use it to implement code that needs to reside in the view
layer (or code that needs to be called from the view layer) and as a
way to keep from writing scriptlet code in my JSPs.
It just so happens that the controller API gives you indirect access
to the request and response objects so you could use them to include
or forward or write directly to the response and all the other stuff
you can do there. But I'd not recommend the controller be used in
this way. I would use the controller to manipulate the TilesContext
and the JSP contexts, but not to actually "do anything" with regards
to changing the destination.
In today's world if I was writing a Struts app with Tiles I would try
to use JSTL, EL, custom tags, (or in JSF, action listeners, etc). to
do things I did in the past with controllers. But I can still see
circumstances where I might want a controller instead.
Think about this: Tiles can be used for page composition outside of
any MVC framework. In that sense it's kind of like a portlet
container. (In fact I think that's how Cedric envisioned it before
JSR-168 came about). So you can compose pages out of JSP fragments
and populate each fragment with a controller that is executed before
the fragment is processed and included. I actually have written a
couple of small webapps that use Tiles in this way and see it as a
powerful feature.
I think we should retain the controller for Tiles definitions (not
sure about the insert tag). I also think we should document the fact
that you can get yourself into all kinds of trouble by making
improper use of the request and response APIs from within the
controller.
Thoughts?
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Some words about proposed changes
Posted by Antonio Petrelli <ap...@apache.org>.
Hi Cedric!
I'm pleased you joined the discussion!
Cedric Dumoulin ha scritto:
> In some case, I have the feeling that we are going backward :-).
I think it is somewhat intentional :-) AFAIK you wrote Tiles as a
stand-alone software, then you integrated into Struts, then we are
removing the dependency, we're going back in the future :-P
> * <get> was changed to <insert> - because we mainly say that we want
> to insert something
Insert in the page you mean? I'd say include, as in <jsp:include>
> * Attributes "template=" and "component=" were changed to "page=" -
> because we specify the page to insert. Tiles is more than a
> templating mechanism, and the inserted page is not necessary a
> template :-). Maybe we can use "tile=" now that tile is a very
> well established name.
This is a nice idea, from my POV
> * The controllers were added to allows stand alone use of tiles to
> be able to do some kind of computation associated to the tiles.
> When used with Struts, there is a redundancy (with the use of
> actions), but when used alone, the controller mechanism is very
> useful to separate view rendering from controller business
The problem with Tiles controllers is that the controller is not able to
choose between different destination pages. It misses an important part
of a controller: the dispatcher.
But using a normal url as a template (or tile :-) ) it can do both
calling the model and dispatching. If you download the latest version
from SVN, there is a test with a simple servlet that includes a (fixed
for the moment) JSP page.
And I think that including a Controller in a View layer technology is
not a good idea.
> It is true that Tiles2 gives us the opportunity to remove all the
> redundancies, but we have to take care to not fall again into the
> previous mistakes :-)
You're the right person that can help us not to make mistakes :-)
Thanks again
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Some words about proposed changes
Posted by Wendy Smoak <ws...@gmail.com>.
On 10/5/06, Cedric Dumoulin <ce...@lifl.fr> wrote:
> * <get> was changed to <insert> - because we mainly say that we want
> to insert something
I _think_ that discussion leaned towards keeping 'insert'.
> * Attributes "template=" and "component=" were changed to "page=" -
> because we specify the page to insert. Tiles is more than a
> templating mechanism, and the inserted page is not necessary a
> template :-). Maybe we can use "tile=" now that tile is a very
> well established name.
This is http://issues.apache.org/struts/browse/SB-21 . I like the
idea of switching to 'tile'. The original comments seemed to indicate
that 'template' was the preferred one. I would have picked
'component'. (To me 'page' is the entire composition, not a piece of
it.)
How does this affect the DTD, which has template, path and page? I
end up horribly confused every time I try to make the TLD and the DTD
match up. The DTD changes are on SB-30:
http://issues.apache.org/struts/browse/SB-30
> * The controllers were added to allows stand alone use of tiles to
> be able to do some kind of computation associated to the tiles.
> When used with Struts, there is a redundancy (with the use of
> actions), but when used alone, the controller mechanism is very
> useful to separate view rendering from controller business
I opened SB-52 for this. http://issues.apache.org/struts/browse/SB-52
> It is true that Tiles2 gives us the opportunity to remove all the
> redundancies, but we have to take care to not fall again into the
> previous mistakes :-)
> Once again, that my feeling after reading some of the mails, and maybe I
> have missed something in the discussions.
Thanks for speaking up! It helps to have someone who knows the
history of why certain decisions were made. :)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Some words about proposed changes
Posted by Greg Reddin <gr...@apache.org>.
On Oct 5, 2006, at 8:45 AM, Cedric Dumoulin wrote:
> I just came across some of the mails about Tiles2. First, I am
> very glad that someone has the time to let Tiles evolve.
> But, I am a little bit disappointed about how the proposed Tiles
> API evolved.
I'm glad you're speaking up and watching what's going on. In many
cases I've been uneasy about the changes I've made simply because I'm
not sure I understood the original intent of things I've removed or
modified. I'm glad you're still around :-)
> * <get> was changed to <insert> - because we mainly say that we
> want
> to insert something
So, have we come to the conclusion that Insert will stay and Get will
go? I'm comfortable with that approach at this point.
> * Attributes "template=" and "component=" were changed to "page=" -
> because we specify the page to insert. Tiles is more than a
> templating mechanism, and the inserted page is not necessary a
> template :-). Maybe we can use "tile=" now that tile is a very
> well established name.
The only problem I have with "tile" is that I would tend to think of
a "tile" as a named definition or something. More often than not I
think of inserting a tile as inserting a definition by name i.e.
tile="headerTile" rather than as inserting a page i.e. tile="/
headerTile.jsp". I like using "template" on the definition tag
because, on a definition, it seems like the "page" really is a
template. It's a page to which parameter values (or attribute
values) will be applied when it is invoked. But I guess you could
see any JSP page as being that way. So there's only a very subtle
difference between a page that is a template vs. a page that is not a
template. It gets really crazy if you think of it this way: The
only time a JSP page is not a template is if it *only* contains
template text. Yuck :-)
In the end I'm ok with using "tile" if that's what everybody else
wants. However, if we go this route I think we need to document
somewhere "What is a tile?" It can be a page. It can be a
template. It can be an attribute, etc. After thinking about it a
bit I'd *really* prefer we use "template" to define a page on a
<definition> tag and use "page" to define it everywhere else (<put>
and <insert>). To me, that's the most clear. But I can go either way.
> * The controllers were added to allows stand alone use of tiles to
> be able to do some kind of computation associated to the tiles.
> When used with Struts, there is a redundancy (with the use of
> actions), but when used alone, the controller mechanism is very
> useful to separate view rendering from controller business
I'll respond more fully to this in response to Antonio, but in
essence I agree with you about this.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Some words about proposed changes
Posted by faisal abdallah <ju...@yahoo.co.uk>.
I have created my own struts tiles and struts framework. That's the beauty of Open Source . And I don't need to check the current or future version
http://www.skillipedia.com
---------------------------------
Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal