On Apr 24, 2006, at 7:57 PM, Michael Jouravlev wrote:
Does using Tiles still makes sense in 2006?
I'm still trying to decide but I'm pretty sure the answer is yes. If I was working on existing code that relied heavily on Tiles I would certainly be glad to know that new development is still taking place. If I was starting a new project and deciding on a layout mechanism I'd have to evaluate Tiles in the context of all the other layout mechanisms currently available and make a decision. I haven't had the time to do such an evaluation so I'm just not sure how to answer that question.
This antiquated sample does not promote good HTML design. It uses table instead of div or span elements, and it uses HTML attributes like "bgcolor".
Yes, I pretty much agree with that. That documentation was lifted almost directly from the documentation that Cedric wrote several years ago when it represented best practice. It was an attempt to get some basic documentation up as quickly as possible in the hopes that people would submit patches to extend and correct it. There is a ticket open to accept documentation patches and you can be that I will commit patches that are submitted.
The concrete page would use code like this [1]: <%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %> <tiles:insert template="layout.jsp"> <tiles:put name="title" value="This is the title." /> <tiles:put name="header" value="header.jsp" /> <tiles:put name="body" value="body.jsp" /> </tiles:insert> I still have to specify all these <tiles:put> tags that refer to particular header/footer files (Definition solves that, see below). What if instead of using <tiles:put name="header" value="header.jsp" /> one would use something like this: <div class="header"><jsp:include page="header.jsp" /></div> and would have an appropriate set of rules for "header" class in a CSS file? Would not it be the same without using Tiles layout file?
Yes, I agree that this pattern doesn't seem to make a great deal of sense. Using Tiles like this does seem to be more overhead than the JSP include tag. I would rarely do it this way though and would normally use tiles defined in an XML file. But I can see a place for this use case. If you want to define your tiles using named definitions but want the values to be based on some dynamic values rather than fixed values as they would in an XML file, you might use this pattern. The advantage of this pattern is that it gives you the ability to extend the named definition and replace the named attributes. But even in that use case, I would have to be able to gain a *lot* from the dynamic values to overcome the disadvantages of error-prone and hard to debug tiles definitions set up in a JSP. In practice I've never done it this way, but have always used the XML file.
Again, what if a JSP file with definitions contained just a list of regular JSP includes for the header, menu and footer, and every include would be wrapped into a div or span with specific CSS id/class? Would not it be quite similar?
It would be quite similar except that you don't have a single name associated with that page that you can reference. With just a very small bit of overhead (IMHO) you can associate a name with the layout and always reference it by name. Then you can make arbitrary changes to the layout (including the JSP page that defines it) without having to change all the code that consumes it. You can also create a sub- layout that extends it and overrides desired parameters without having to write a whole new layout. That's why I would almost *always* choose tiles over simple jsp:includes. YMMV :-)
Thanks, Greg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
