Return-Path: 
 <struts-user-return-107431-apmail-jakarta-struts-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-struts-user-archive@www.apache.org
Received: (qmail 23220 invoked from network); 1 Mar 2004 13:38:03 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 1 Mar 2004 13:38:03 -0000
Received: (qmail 25806 invoked by uid 500); 1 Mar 2004 13:37:25 -0000
Delivered-To: apmail-jakarta-struts-user-archive@jakarta.apache.org
Received: (qmail 25758 invoked by uid 500); 1 Mar 2004 13:37:25 -0000
Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:struts-user-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:struts-user-subscribe@jakarta.apache.org>
List-Help: <mailto:struts-user-help@jakarta.apache.org>
List-Post: <mailto:struts-user@jakarta.apache.org>
List-Id: "Struts Users Mailing List" <struts-user.jakarta.apache.org>
Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
Delivered-To: mailing list struts-user@jakarta.apache.org
Received: (qmail 25641 invoked from network); 1 Mar 2004 13:37:24 -0000
Received: from unknown (HELO Sirius.iaeste.tuwien.ac.at) (128.130.57.131)
  by daedalus.apache.org with SMTP; 1 Mar 2004 13:37:24 -0000
Received: from kamikaze by Sirius.iaeste.tuwien.ac.at with local (Exim 3.35
 #1)
	id 1Axnbn-0000KP-00; Mon, 01 Mar 2004 14:37:23 +0100
Date: Mon, 1 Mar 2004 14:37:23 +0100
From: Axel Gross <axel.gross+resu-sturts@iaeste.at>
To: Struts Users Mailing List <struts-user@jakarta.apache.org>
Subject: tiles - smth like addToList?
Message-ID: <20040301133723.GA29023@iaeste.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-Operating-System: Linux
Sender: =?iso-8859-1?Q?Axel_Gro=DF?= <kamikaze@iaeste.at>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Hi people!

Concerning tiles definition and extension of those.
First part-o-mail: concrete problem
Second part-o-mail: a more general approach (beginning of it ;)

  First part:
I see the need for extending the entries of a putList without overriding the
entries in the super definition.
Example:
 <definition name=".head.common" path="htmlHead.jsp">
	<putList name="httpEquiv">
		<item value="pragma" link="no-cache" />
		<item value="cache-control" link="no-cache" />
		<item value="expires" link="0" />
	</putList>
 </definition>

 <definition name=".head.project" extends=".head.common">
	<putList name="httpEquiv">
		<item value="expires" link="1" />
		<item value="description" link="tiles definition extension example" />
	</putList>
 </definition>
so usually this would replace the list in .head.common with the one in
.head.project
desired behaviour would be to just add the new entries ("description") and overwrite those
which are already present ("expires").
Even without the feature to overwrite old values, it would be really nice to have
a tag for that (i.e. <addToList name="httpEquiv">..).
At the moment I use 'specialised' definitions (wrapping those attributes
likely to change in another definition), as I didn't go deep into tiles code until
now. But that just works in some cases.

  Second part:
I think to have this as a general capability would make a lot of sense
(virtually adding+replacing nodes in the definition to those the superdefinition 
at the same place of hierarchy)
Especially if the other config files are going to support extension, too.
So questions arise;
 did anybody do this?
 do others think there's a real need?
 how to judge, which nodes should be overwritten?


thanks for your patience,
Axel

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org