Large websites often need a common Look and Feel (L&F). If the L&F is hard coded in all pages,
changing it becomes a nightmare: you would have to modify nearly all pages. When you are using JSP include, you create the layout of the website within the page and then place
the actual view component (JSP). Hence you need to repeat the same layout logic to every page causing
repetition in the web page. This also discourages you to change the view of the website at a later time
as you may have a lot of pages to modify.
o I18N support for locale-specific loading
“Tiles” is the solution for this problem. Tile is an area or region on web page. Tiles is the technology
which is used to create view of a website. Using Tiles you can define the layout as a template, can
create complicated layouts and use them through out the application for consistent layout. The purpose
of layout is to assemble a group of tiles to specify the format of page. As it is a layout, you insert
placeholders (using Tiles insert tag) instead of actual view components (JSPs). The values for the
placeholders are defined by an XML. If you want to change the view of the application you can do so
by changing the layout only and can save a lot of time.
With Tiles you can do things such as:
o Screen definitions that include inheritance
o Templating: you can create templates and can use them again and again o Layouts for common pages, menus, and portals
o Dynamic page building
o Reuse tiles
With Tiles you can do things such as:
o Screen definitions that include inheritance
o Templating: you can create templates and can use them again and again o Layouts for common pages, menus, and portals
o Dynamic page building
o Reuse tiles
9. Tiles vs. JSP Include
9.1. Advantage of Tiles over JSP include
9.1. Advantage of Tiles over JSP include
-
Code Repetition is reduced
Use of Tiles reduce the code repetition to a great extent. Code repetition is bad but repetition of layout logic could be worst. Tiles also handle this issue. As you have layout templates based on which all the pages are combined, you don't need to repeat the code for layout. Other view components are also reusable and can be used in the same application at other places reducing the code repetition.
-
Low coupling between pages
Coupling is the degree of interactivity between two entities. It is always suggested to minimize coupling between unrelated classes, packages, and so on. Same principle is applied to view components. Tiles reduce the coupling between unrelated view components.
-
High layout control
Tiles provide great layout control by providing layout templates.
-
I18N support for locale-specific loading
-
Dynamic Page building
Pages are built dynamically in tiles. You can control the page view by configuring it through xml.
-
Elimination of duplicate and redundant information
Tiles eliminate the duplicate and redundant information in the configuration file by providing Tiles inheritance.
-
Central location for view components
Tiles save definition of all the components at one place (in tilesDef.xml) and hence can be modified easily when required.
-
Increases the number of pages
-
Increases complexity
Tiles increase complexity by introducing another layout page. Understanding and implementing templating can also be difficult at initial stages.
-
Big API
Tiles have a bigger API set which may be difficult to understand for getting full benefit of tiles.
-
You have to specify a name to any component you create.
I am a big believer in the Tiles framework. It's main advantage, in my
viewpoint, is its ability to increase reuse across the presentation
tier of an application

With Tiles a developer can set up a few Tile definitions (templates)
that represent the different page layouts across a web app

definition can have both concrete JSPs as well as empty Tiles. Then,
through Tile inheritence, each template can be extended n times to
create any number of pages. Say that a web app

footer across 10 pages. Tiles allows the developer

for the header, one JSP for the footer, one Tile definition, and 10
JSPs for the body of each page. If the header JSP changes the change
ripples through all pages without any need to change the Tiles XML.
Sure, you could use jsp:include and get a similar result but you would
lose the flexibility of the XML configuration and the inheritence that
Tiles provides you. In the near term it will save development time
with each new page that you create that fits into one of the templates
you have defined. In the long run it will make the application much
easier to maintain.
To add to that point, Tiles helps you code views in a way that allows
you to minimize the number of objects placed in the session scope.
Many times you see a developer using a traditional MVC where a servlet
can only dispatch to only 1 jsp.
The jsp is normally called main.jsp but it calls numerouse includes.
Main.jsp accepts the request attributes, but included jsp, that may
also include other jsp for presentation purpose may not, but should
have access to the object added to the request. So many developers

would capture it in main.jsp and then add it to the session. This is
not scalable. So with tiles you dont have to do that the inheritence
allows you to access the request scope attributes at any level.
No comments:
Post a Comment