Looks good to me, nice job!
Don
Ted Husted wrote:
The PRC is asking for the usual press releases for ApacheCon. I
thought we might want to forward something about Struts 2.0.1.
I appended a proposed draft to the release plan.
*
http://cwiki.apache.org/WW/release-plan-201.html#ReleasePlan2.0.
The PRC is asking for the usual press releases for ApacheCon. I
thought we might want to forward something about Struts 2.0.1.
I appended a proposed draft to the release plan.
*
http://cwiki.apache.org/WW/release-plan-201.html#ReleasePlan2.0.1-DraftAnnouncementforApacheCon
-Ted.
-
Great! When you get a chance, take a look at the patch I just submitted
and let me know what you think. I'd be happy to work with you to iron
out any details.
https://issues.apache.org/struts/browse/WW-1328
Updating the core ftl templates to utilize this feature will be tedious,
but I'll giv
On 10/5/06, Nathan Bubna <[EMAIL PROTECTED]> 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 c
I think "controllers" should stay, but the name should be changed.
Call them ViewPreparers or something...
On 10/5/06, Greg Reddin <[EMAIL PROTECTED]> 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
On Oct 5, 2006, at 10:50 AM, Antonio Petrelli wrote:
Greg Reddin ha scritto:
On Oct 5, 2006, at 2:46 AM, Antonio Petrelli wrote:
Greg Reddin ha scritto:
But don't forget about the tag as well.
It's semantics are quite different from . How
would it be affected if we removed the GetTag
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, t
Antonio Petrelli ha scritto:
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 In
Greg Reddin ha scritto:
On Oct 5, 2006, at 2:46 AM, Antonio Petrelli wrote:
Greg Reddin ha scritto:
But don't forget about the tag as well. It's
semantics are quite different from . How would it be
affected if we removed the GetTag?
I forgot a thing:
uses GetAttributeTag that does not
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
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 depe
On 10/5/06, Cedric Dumoulin <[EMAIL PROTECTED]> wrote:
* was changed to - 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 spe
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
On Oct 5, 2006, at 2:46 AM, Antonio Petrelli wrote:
Greg Reddin ha scritto:
But don't forget about the tag as well. It's
semantics are quite different from . How would it
be affected if we removed the GetTag?
I forgot a thing:
uses GetAttributeTag that does not extend
neither GetTag
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 redunda
Antonio Petrelli ha scritto:
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.
Taken from tlddoc:
http://struts.apache.org/1.x/struts-tiles/tlddoc/tiles/get.html
Greg Reddin ha scritto:
But don't forget about the tag as well. It's
semantics are quite different from . How would it be
affected if we removed the GetTag?
I forgot a thing:
uses GetAttributeTag that does not extend neither
GetTag nor InsertTag. Anyway I still think also this tag can be
Wendy Smoak ha scritto:
On 10/4/06, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
I think that is the most used, even I wrote some tests
(in the test webapp) using and I am used to write only
But we are cleaning Tiles from the unnecessary and I like
more (going against my own interests :-) ),
Niall Pemberton ha scritto:
If the decision is to have get as the standard then
I would argue to keep insert for backwards compatibility.
The problem is that Tiles 2 will not be compatible with previous version
of Struts-Tiles, so many changes have been made on the tags to remove
the redundan
Greg Reddin ha scritto:
...whereas would say "get a tile or attribute from context
and let me do something with it later."
Isn't it the tag that does such a thing?
But don't forget about the tag as well. It's
semantics are quite different from . How would it be
affected if we removed th
20 matches
Mail list logo
