struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <...@Germuska.com>
Subject Re: [Standalone Tiles] Changing the Semantics of the InsertTag
Date Wed, 14 Jun 2006 12:23:45 GMT
Would you consider some kind of compatibility mode?  That is, before 
you remove support for these, could there be a way for people to 
configure things for a more strict or more compatible evaluation, to 
ease migration?  It seems like the closest you can get to deprecation 
warnings in tag libs/JSPs.

Just a thought.   I don't have a ton of time to put into it myself, 
and I wouldn't make a big fuss if it weren't done.

Joe

At 5:37 PM -0500 6/13/06, Greg Reddin wrote:
>Ticket SB-21 [1] seeks to simplify the Tiles taglib API.  First, 
>it's a given that this will break backwards compatibility.  You 
>can't reduce an API without breaking compatibility.  But as long as 
>we're seeing this version of Tiles as a rework, I don't think it's a 
>problem.  Also, I don't think it's a difficult thing to fix in 
>existing applications.  No functionality will be removed, but 
>redundant hooks to the same functionality will be removed.  Finally, 
>I think this will be one of the greatest improvements to the 
>usability of Tiles.  I'm currently working on a patch to implement 
>this.
>
>Of the attributes that are currently supported by InsertTag, I 
>believe the following are redundant:
>
>1)  attribute, definition, name could all be resolved to name.
>2)  component, page, and template could all be resolved to template.
>
>In addition the name attribute can be interpreted as either a 
>pointer to a Tiles definition or attribute or an URL, which 
>essentially makes it equivalent to page and template.  I propose 
>that we reduce all these meanings down to the "name" attribute. 
>IOW, name can be a definition name or an attribute name.  I suspect 
>this is how Tiles is being used in 90% of applications anyway.  I 
>know that's how I use it.  Further, I propose that we reduce all the 
>URL-based attributes to the "template" attribute.  So if you want to 
>directly insert a page you must use the template attribute.
>
>The net result is that you can use the insert tag in the following ways:
>
><tiles:insert name="someName"/>
>- to insert a Tiles definition or attribute.
>
><tiles:insert template="/somepage.jsp"/>
>- to insert a URL.
>
>I'm not really sure what the use of the beanName and beanProperty 
>values are, so if someone wants to enlighten me on that, I'd 
>appreciate it.
>
>Finally, I personally don't see the use for including a 
>controllerClass or controllerUrl in the insert tag.  IMO, if you 
>want to do something like that you should use the definition tag 
>instead.
>
>I still intend to completely support attributes defined in the tag 
>body as such:
>
><tiles:insert name="someDefinition">
>   <tiles:put name="someAttribute" value="someValue"/>
></tiles:insert>
>
>And the other attributes like flush, ignore, and role will continue 
>to function as always.  Have I left out any major uses of the insert 
>tag?  Does this change remove any functionality that anyone is 
>currently relying on?
>
>Thanks,
>Greg
>
>[1] http://issues.apache.org/struts/browse/SB-21
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org


-- 
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com    

"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
	-- Robert Moog

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


Mime
View raw message