On 4/24/06, Rick Reumann <[EMAIL PROTECTED]> wrote:
> Michael Jouravlev wrote:
>
> > So, the question I am asking: what are the real benefits of using
> > Tiles if I use JSP includes + XHTML/CSS for layout/styling? Can most
> > of Tiles features be implemented with XHTML/CSS?
>
> I guess some of it comes to a personal preference in regard to the
> dynamic content stuff that I didn't see you mention (or I read over your
> post too quickly).
No, I haven't mentioned it, thanks for taking time to explain it.
> For example what about things where your "header" section needs a title
> to display in the html, or what if you quickly want to change around
> what pages get 'injected' (for lack of a better word) with a particular
> div? To accomplish this without something like tiles, you 1) have to set
> up certain things in the request in your Action before you go to your
> page and 2) you have to have jstl logic to decide whether or not to
> display the information. Personally I find it much cleaner to have this
> stuff defined in one place. So for example, lets look at your master
> layout...
>
> <jsp:include page="masterLayout.jsp">
> <div class="content">
> //all your content
> </div>
>
> masterlayout.jsp
> ----------------
> <div class="header"><jsp:include page="header.jsp"/></div>
> <div class="footer"><jsp:include page="footer.jsp"/></div>
>
> header.jsp
> ----------
> SOME COOL LOGO
>
> { Dynamic "MY SUPER TITLE" }
>
> SOME OTHER LOGO
> more other images
> -------------------
>
> Now in the above, how are you going to get your title into this header
> jsp? The only way I know of is that you'd have to set it up ahead of
> time in your action. What if someone decides that title needs to change?
> Personally I'd rather find all the titles in one place
> (tiles-definitions.xml) than have to find what Action it it is in and
> where in the Action you set it up.
If it is in the xml file, it is not dynamic anymore, is it? Or are you
saying that I can set title for every composite page? (I am
researching Tiles now, haven't worked with it before). In the latter
case, how is this better than setting a request-scoped variable right
in the composite page before <jsp:include page="masterLayout.jsp">
tag? Ok, maybe it is better, because all dynamic or semi-dynamic stuff
is kept off the pages. But if the value is a really dynamic one, say
you read it from a database, then you cannot set it in the definition
file anyway, can you?
I think this is the problem with Tiles, it is not a component
technology, it is a view composition technology. It allows me to
combine JSPs, but in Struts JSPs are considered as data-aware dynamic
HTML, so JSPs are pretty dumb in terms that they do not contain
controller code or business-related code. Therefore JSPs should be
fronted with Struts action. Now can you explain me, if I have a
composite page out of three JSP files, how would I run their
corresponding setup actions before the page is composed?
Instead of including JSP pages I would include Struts actions (Will it
work with Tiles? I haven't tried it yet) like this (seems that I can
use include directive instead of dynamic include tag here):
somepage.jsp:
-------------
<%@ include file="masterLayout.jsp" %>
<div class="content">
//all your content
</div>
masterlayout.jsp
----------------
<div class="header"><jsp:include page="header.do"/></div>
<div class="footer"><jsp:include page="footer.do"/></div>
header.jsp
----------
SOME COOL LOGO
${headerForm.mySuperTitle}
SOME OTHER LOGO
more other images
-------------------
This way all my dynamic stuff is encapsulated into respective Struts
action/JSP pairs. I am guaranteed that setup action is always called,
and I can pull out whatever dynamic data I want, say from the
database.
> The other thing is that I'm still not convinced of the magic and wonders
> of css for layout. Personally to me it's often black magic voodoo. Sure,
> I'm sure some will say it's easy ...bla blah... BS I say. Complex
> layouts with css is ANYTHING but easy or intuitive. Sure for simple
> stuff it's fine, but I'll be willing to race almost any average css user
> in designing some complex layouts. They can use only css and divs. I can
> use tables. I bet you I'll be done much faster and it'll work in all
> browsers and it will be easy to understand (ok yes it will 'look' more
> cluttered, but it'll still be intuitive.) Ok done ranting about css
> positioning:)
I won't get into this, but csszengarden or alistapart are convincing
enough. Yes, CSS takes different skills, but this is the price that
has to be payed for better separating content and styling.
> PS: when you mention:
>
> Michael>>>>>
> <%@ 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).
> <<<< /michael
>
> The "all these <tiles:put>" things in the above is only true for things
> that 'change' like the body.jsp and the title. Probably things like the
> header and footer would be part of the main.layout which you would be
> extending in your definition. (You typically set up a few layouts and
> all your pages then extend the ones they need.)
Yes, I got that. I can use a definition section.
> And also remember you still have to deal with getting a dynamic title
> into certain sections. You often can't always have it be in your main
> content page so it somehow has to become part of your header section
> (imagine the case I mentioned where you want to show a title between
> certain header images.. which is quite common.)
As I explained, instead of composing view by including JSP fragments,
I would include Struts setup actions, where every setup action would
forward to a corresponding JSP file, which would render appropriate
markup.
Tiles is that it works on an View layer, after controller layer
(actions) finishes with its job. Despite that a composite page is
built out of different JSP fragments, these fragments are just views.
They usually do not obtain dynamic data themselves, this is actions'
job. After the composite page has been built, it is solidified, and
whatever is submitted from the browser is sent to the page action, not
to the action of a particular fragment. I am talking about composing
real components, that can accept input as well as render themselves.
Including Struts actions instead of JSP files is the first step in
this direction.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
