Hi,
I haven't looked much into SiteMesh, but, just looking at the overview,
it seems to me that you still have to generate the content of the
different sites that you want to "mesh", and if they look totally
different then you are out of luck.
We are using the same approach that Jeff is talking about and we don't
consider XML/XSL to be that slow, as using precompiled stylesheets we
boosted aour performance by a factor of three and the "heaviest"
operation is accesing the database. As XSLT implementations improve day
by day, I hope this will be less of a problem in the future. And using
XML as the common ground is, IMHO, a very good approach to integrating
different applications as you can use common stylesheets to integrate
the different sources.
But I won't pretend it is a perfect solution or that everybody should
use it. That's what we use because it fits well into our team and
requirements. And, Jeff, we also created our own framework to basically
allow us to get the XLM content from various sources, including directly
from PLSQL, so if you want we could talk about it privately. We GPLd our
framework but we haven't publicized it as we don't have much time to do
so.
Just my 2c,
Dan
Mike Cannon-Brookes wrote:
>
> Noooooo - XML/XSL is too slow / fugly to actually use day to day (IMHO)
>
> I'd advise you to check out SiteMesh - it's built for this exact purpose!
>
> http://www.opensymphony.com/sitemesh
>
> Quite simply you provide JSP based decorators which are mapped to URIs.
>
> Download and install the sample app, it's the only way to learn about it.
>
> $10 says you're using it within a week ;)
>
> -mike
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
> > Sent: Friday, May 11, 2001 7:12 AM
> > To: Orion-Interest
> > Subject: RE: Standar Template
> >
> >
> > I've iterated through several solutions to this problem and can offer
> > some advice:
> >
> > I started out using option 1 as you describe. I quickly noticed that
> > *every* page contains the definition of the layout and look of the
> > website. What if I wanted to put the navigation bar on the right
> > instead of the left? I would have to modify *every single page* in my
> > website. Yuck.
> >
> >
> > My next step was to put the "container" code in separate head/foot JSP
> > files and @include them like this:
> >
> > <%@ include file="head_stuff.jsp" %>
> > <p>
> > My content
> > </p>
> > <%@ include file="foot_stuff.jsp" %>
> >
> > Which at least puts all the look and feel stuff in a handful of places.
> > But my site has different templates for the "logged in" user vs the
> > welcome/signup screens and a few other special cases as well. It
> > quickly became a pain to keep track of all the different headers and
> > footers, and in any case opening tags in one file and closing them in
> > another really sucks. Yuck.
> >
> >
> > Next step was option 2 as you describe. I created
> > "template_inside.jsp", "template_outside.jsp", etc which contain all the
> > layout structure and then include the appropriate content file based on
> > a parameter. Since I'm using an MVC framework, this is pretty easy to
> > do.
> >
> > This is the best option I've described so far, and it works. But it's
> > not very sophisticated, and it doesn't make having multiple layers very
> > easy. Fortunately I'm working on my own time, so now I'm moving on to
> > the fourth generation of my website content:
> >
> >
> > This sort of templating is where XSLT really shines. Rather than
> > creating templating layers from the top down, XSLT allows you to start
> > at the bottom and build up, successively transforming the input.
> > Wrapping (in a layout template) is just one kind of transformation.
> > Each step has no need to know anything specific about the previous step;
> > it's all just based on transformation rules.
> >
> > I'm still near the bottom of the XSLT learning curve, but I'm already
> > amazed at how powerful it is. It's also a lot easier to pick up than I
> > had expected from first looking at a sample.
> >
> > The only problem with using XSLT in a web application is the lack of
> > framework support. Cocoon did not make a favorable impression on me (to
> > say the least). I wanted something that provides a simple MVC paradigm
> > like WebWork or (not-so-simple) Struts but uses XSLT for the view
> > templating. So I (and a friend) sat down and wrote it. Tomorrow we'll
> > send out a link to the sourceforge site; we're still working on the
> > documentation and examples.
> >
> >
> > In summary: For a simple approach, Option 2 as you describe isn't bad.
> > For (IMNSHO) a more elegant and powerful approach, it's worth looking
> > into XSLT.
> >
> > Jeff Schnitzer
> > [EMAIL PROTECTED]
> > http://www.similarity.com (still using WebWork, but not for long :-)
> >
> >
> > > -----Original Message-----
> > > From: Dave Ford [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, May 10, 2001 12:17 PM
> > > To: Orion-Interest
> > > Cc: Dan Tharp
> > > Subject: Standar Template
> > >
> > >
> > > I want to create a web app in which every page on the site
> > > has a standard
> > > header along the top and a standard menu along the left edge (a pretty
> > > standard thing).
> > >
> > > I came up with 2 ways of doing this:
> > >
> > > 1. Use a table tag and jsp:include tags on EVERY page:
> > >
> > > <table>
> > > <tr>
> > > <td><jsp:include page="standardHeader.jsp"/></td>
> > > </tr>
> > > <tr>
> > > <td colspan="2">
> > > <table>
> > > <tr>
> > > <td valign="top"><jsp:include page="/menu.jsp" /></td>
> > > <td valign="top">
> > > THIS IS WHERE THE PAGE-SPECIFIC CONTENT (i.e. the body)*
> > > </td>
> > > </tr>
> > > </table>
> > > </td>
> > > </tr>
> > > </table>
> > >
> > > 2. Invert the above solution to create one master template
> > > (or controller)
> > > and have the content page name passed in as a parameter. Here
> > > would be the
> > > master template-controller page:
> > >
> > > <table>
> > > <tr>
> > > <td><jsp:include page="standardHeader.jsp"/></td>
> > > </tr>
> > > <tr>
> > > <td colspan="2">
> > > <table>
> > > <tr>
> > > <td valign="top"><jsp:include page="/menu.jsp" /></td>
> > > <td valign="top">
> > > <jsp:include
> > > page="<%=request.getParameter("contentPage")%>" />*
> > > </td>
> > > </tr>
> > > </table>
> > > </td>
> > > </tr>
> > > </table>
> > >
> > > The key difference between these two architectures are best
> > > understood by
> > > looking at the 2 lines with the * at the end. Also, in option
> > > 2, there is
> > > only one copy of the above code. In option 1, there is one
> > > copy "per content
> > > page"
> > >
> > > Q1: Does anyone have any preference between options 1 and 2?
> > > Q2: Is there a better way of achieving this result?
> > > Q3: Do either have any negetive drawback I need to consider?
> > > (I will be
> > > converting an entire site)
> > >
> > > By the way, I'm currently achieving this effect VERY easily
> > > using good old
> > > client-side html frames. But due to popular demand, framse must go.
> > >
> > > Dave Ford
> > > Smart Soft - The Java Training Company
> > > http://www.smart-soft.com
> > >
> > >
> > >
> >
> >
