Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Should I ditch Tiles in AppFuse?

I've haven't been developing applications with AppFuse since May. Instead, I've been using Equinox. One of the main things in Equinox I've grown to love is SiteMesh. It's worked in all the webapps I've written, which utilize frameworks like Struts, Spring MVC, WebWork, Tapestry and JSF. Tiles will only work in 3 of those.

I think it's time to make an executive decision on AppFuse and ditch Tiles in place of SiteMesh. It's faster and easier to develop with, and it doesn't get in your way. In fact, I didn't have to change a single line of SiteMesh-related code to support any of the aforementioned frameworks. Furthermore, using SiteMesh would also greatly reduce the duplicate between frameworks. I've thought about keeping Tiles around, but it's a pain in the ass to maintain parallel sets of documentation.

Whaddya think - any reason you can think of to keep Tiles? I can't. In fact, I think I'd cringe if I had to start my next AppFuse-based project w/o SiteMesh.

Posted in Java at Aug 18 2004, 10:11:56 AM MDT 33 Comments
Comments:

I would be in favor of replacing Tiles with SiteMesh

Posted by Greg Jones on August 18, 2004 at 10:41 AM MDT #

Go for it! I have yet to migrate from Tiles to SiteMesh for my own projects, but, this would give me the impetus to do so.

Posted by Van Riper on August 18, 2004 at 10:44 AM MDT #

I agree with Van, - i haven't yet used SiteMesh, but I know tiles can be troublesome and if you can't think of a reason to keep tiles, then i say make the switch.

Posted by Mark Janveaux on August 18, 2004 at 10:53 AM MDT #

Great Matt! (The AppFuse is in a way that user without experience can work with) Now I can back and work with appfuse (I'm using equinox and as Matt said, SiteMesh is much more easy). The next that I need to understand is StrutMenu - Or is it another one? Will you put any chapter about SiteMesh in your book? I'd like!

Posted by Gilberto C. Andrade on August 18, 2004 at 11:00 AM MDT #

SiteMesh! SiteMesh! SiteMesh! :)

Posted by Joe Walnes on August 18, 2004 at 11:01 AM MDT #

I've never used SiteMesh, but I like the fact that it is not dependent on a Framework like struts and tiles. It does however require servlet filters(2.3 I think), where tiles does not. I also agree with Van, I've been wanting to look into SiteMesh for a while, and this might be a good excuse ;)

Posted by Mike T on August 18, 2004 at 11:16 AM MDT #

Ditch Tiles. Go SiteMesh!

Posted by Mathias Bogaert on August 18, 2004 at 11:30 AM MDT #

Wow, I don't think I've ever seen a blog entry on anything with so much unanimity... I think that's a fair assessment of Sitemesh vs. Tiles.

Posted by Jason Carreira on August 18, 2004 at 11:45 AM MDT #

Hey Matt. I have no experience with SiteMesh, but like Jason C., I don't think I've ever seen such agreement on hardly *anything*. My only concern would be that I am currently starting to build a web app on appfuse using tiles so I'm wondering what release you're thinking of switching in? I assume that SiteMesh handles templating as does tiles, how difficult is it to switch over? That said, I'm hung up on a tiles problem right now, so maybe that tells the story! -=j=-

Posted by jack hart on August 18, 2004 at 12:12 PM MDT #

!From the AppFuse mailing list - maybe one of you SiteMesh developers can answer these questions: * Do you have similar mechanism in SiteMesh like Tiles Controllers? * Is it possible to load SiteMesh templates from database? * Can you extend SiteMesh like you can Tiles RequestProcessor? Personally, I've never had a ''real'' need for controllers, loading templates from a database or extending RequestProcessor.

Posted by Matt Raible on August 18, 2004 at 12:24 PM MDT #

do it!

Posted by Dan Allen on August 18, 2004 at 12:42 PM MDT #

Use SiteMesh, remove Tiles !

Posted by Lars Fischer on August 18, 2004 at 12:44 PM MDT #

!Ok, the aggreement is a bit biased. I'm the original author of SiteMesh and a few other people who commented are also involved in it - I'm sure if you speak to the Tiles people you'll get another story ;) * Do you have similar mechanism in SiteMesh like Tiles Controllers? No - because with SiteMesh you don't need one! A decorator can be generated by anything, so for instance instead of decorating a page with my-decorator.jsp, you could use my-decorator.do (or whatever) to point to another Action, from framework of your choice. Seems pointless to invent another API for actions when there are plenty of good ones already, or Struts. * Is it possible to load SiteMesh templates from database? Yes! Your decorator can be a Servlet/Action/JSP/whatever that loads content from a database. You can also define your own DecoratorMapper implementation which is basically a strategy that chooses which decorator to use for each request (it defaults to looking in a config file). This can be used to do more dynamic things such as different decorators based on locale, user, category, browser, whatever. * Can you extend SiteMesh like you can Tiles RequestProcessor? Can you be more specific? SiteMesh has been designed to be a non-intrusive framework so you can use whatever technologies you want to get the job done without constraining you to an API. If you can do it without SiteMesh, then there's no reason why it would get in your way.

Posted by Joe Walnes on August 18, 2004 at 01:47 PM MDT #

Matt, where is the download link for Equinox?

Posted by Andre Mermegas on August 18, 2004 at 02:13 PM MDT #

You can download it from it's homepage - click on the "Documents & Files" link on the left. Or you could use this direct link.

Posted by Matt Raible on August 18, 2004 at 02:23 PM MDT #

Scrap Tiles and use SiteMesh.

Posted by gerryg on August 18, 2004 at 03:29 PM MDT #

I've just used a tiles controller to make a pda friendly website, changing tiles attributes (e.g. css files) based on user browser. Can this be done with SiteMesh?

Posted by Carlos Sanchez on August 18, 2004 at 04:03 PM MDT #

I would ensorse dropping tiles. Sitemesh is a much cleaner implementation.

Posted by grego on August 18, 2004 at 04:58 PM MDT #

> I've just used a tiles controller to make a pda friendly website, changing tiles
> attributes (e.g. css files) based on user browser. Can this be done with SiteMesh?

Carlos, yes. SiteMesh comes bundled with something called the AgentDecoratorMapper which allows you to select a decorator based on the User-Agent HTTP header. Once configured, all you have to do is complement your mydecorator.jsp with mydecorator-ie.jsp, mydecorator-lynx.jsp, mydecorator-pda.jsp, etc and SiteMesh will automatically choose the best fit.

Posted by Joe Walnes on August 18, 2004 at 09:53 PM MDT #

A bit redundant, but.. drop Tiles, go for SiteMesh, it rocks!

Posted by Pål Brattberg on August 19, 2004 at 02:21 AM MDT #

> Can you extend SiteMesh like you can Tiles RequestProcessor?
>> Can you be more specific? SiteMesh has been designed to be a non-intrusive framework so you can use
>> whatever technologies you want to get the job done without constraining you to an API. If you can do it
>> without SiteMesh, then there's no reason why it would get in your way.

For examples, check: <ul class="glassList">
  • http://www-106.ibm.com/developerworks/java/library/j-integrate/
  • http://stxx.sourceforge.net/ for StxxTilesRequestProcessor.
  • Posted by Ville on August 19, 2004 at 02:52 AM MDT #

    Ville, can you explain what it is you actually want to do? With the SiteMesh model, there's often a much simpler way and I can't figure out what the TilesRequestProcessor actually does.

    Posted by Joe Walnes on August 19, 2004 at 04:14 AM MDT #

    Joe, you might want to override default behaviour of TilesRequestProcessor if you're going to implement your own security mechnanism.

    When a request comes in, it gets passed to this request processor, there you can check if user is already authenticated, and then check if he has rights to invoke requested action. From there you can redirect to either login action or to forbidden action or continue normal flow.

    I found this solution quite handy and elegant, especially compared to not-standardized realms in tomcat.

    Needless to say, that all your jsps should go beneath WEB-INF, so only actions will be exposed.

    Posted by Vadim on August 19, 2004 at 05:50 AM MDT #

    Vadim, although I've never used Sitemesh or Tiles, it seems like what you're trying to do can be done with another filter in your filter chain. IIRC, Appfuse has a login filter that does user authentication similar to what you're asking.

    Posted by Ben C on August 19, 2004 at 09:02 AM MDT #

    Ben, I know there are different options. First I also tried to get into say SecurityFilter, but finally ended up with my own subclass of TilesRequestProcessor which is only 120 line long, which is almost static code and can be copy/pasted from a project to a project without any hassle. From the other hand, flexibility it gives to you is incredible.

    Posted by Vadim on August 19, 2004 at 10:00 AM MDT #

    I have used Tiles and did not see the need to explore yet one more tool. However, I support the move to trade Tiles for SiteMesh if it helps reduce the ever increasing number of product dependencies for an application. I will try AppFuse since it appears that it helps group and use several tools without necessarily being too fluent with all of them. A quick listing under AppFuse shows the following list: java, Ant, Spring, Tomcat, XDoclet, iBATIS or Hibernate, JUnit, Cactus, StrutsTestCase, Canoo's WebTest, Struts Menu, Display Tag Library, OSCache, JSTL, Struts, Tiles, SiteMesh. These are 17 in total without counting XML, JEdit, Eclipse et al and counting iBATIS/Hibernate as one. Trading SiteMesh for Tiles does not necessarily reduce the count but hints of trading Struts and Struts-related entries for Spring and gradually reducing the count; this seems to be a move in the right direction. Matt: how about Struts Menu? is it here to stay? is there an alternative ideally using functions under an existing Tool such as SiteMesh ? Thanks;

    Posted by bolivariano on August 19, 2004 at 04:59 PM MDT #

    bolivariano - you'll be disappointed to know that I'm not that motivated to reduce the dependency count or remove Struts in favor of Spring. The goal of AppFuse is to make starting and developing J2EE web applications easier. If that requires more JARs, so be it - I don't mind. As for the different MVC options AppFuse provides - the reason I'm adding more options (i.e. Spring MVC and WebWork) is simply to allow users to choose their framework of choice. If I find that one MVC option is <em>vastly</em> superior to another, I might standardize and rip out the rest - but that's unlikely. Developers seem to be almost religious about their web framework of choice - probably because they've invested so much time in learning it.

    Posted by Matt Raible on August 19, 2004 at 05:07 PM MDT #

    RE: Struts Menu. I don't see any reason to remove it - unless a better open-source option comes along.

    Posted by Matt Raible on August 19, 2004 at 05:17 PM MDT #

    Joe, check the examples I gave above - those are real-life cases where someone has extended Tiles RequestProcessor.

    If there is need to override default behaviour of SiteMesh what would you do? Make another filter?

    Posted by Ville on August 20, 2004 at 12:18 AM MDT #

    Vadim,

    Using a layout library such as Tiles to do authentication seems like a good solution to you?

    Also, you said all the right words: ...which is almost static code and can be copy/pasted from a project to a project without any hassle... ... Mmm, the golden principle of code re-use: copy-paste!

    Posted by Santa Claus on August 20, 2004 at 01:16 AM MDT #

    Go for it matt.. as a tiles user is really troublesome to keep a definition for every page i want to be decorated... and in a project that has like a 100+ pages, the tiles XML definition can look a pretty bit scarier...

    Posted by Johann Reyes on August 20, 2004 at 05:35 AM MDT #

    Yo, Santa! With the same success one could extend Struts' RequestProcessor, which is parent of TilesRequestProcessor (if you're not using Tiles this one intercepts requests). Sounds more proper? Also reusing should be done within reasonable limits. I don't care how to reuse 120 lines of code with this specific functionality, which is olny used once per project.

    Posted by Vadim on August 20, 2004 at 05:43 AM MDT #

    Unless the behaviors you are introducing to your extension of TilesRequestProcessor are layout-specific, shouldn't you just be able to have your custom request processor override RequestProcessor instead of TilesRequestProcessor, and use SiteMesh for your layout? SiteMesh does not care -- it just decorates the resulting request. (Hmmm, though since I have never tried it, I am not sure what would happen if you applied several differnet struts actions in a single decorator.)

    Posted by 66.27.52.214 on August 20, 2004 at 06:22 PM MDT #

    Post a Comment:
    • HTML Syntax: Allowed