We finally released our framework, so I have some breathing time now :-)
I'd love to take a look to see if we can find synergy. The only caveat
is that I would like to avoid GPL; code would need an MIT/BSD/Apache (or
equivalent) license.
If you're interested, take a look at Maverick:
http://mav.sourceforge.net
Later!
Jeff
> -----Original Message-----
> From: Daniel Lopez [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 12:27 AM
> To: Orion-Interest
> Subject: Re: Standar Template
>
>
> 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
> > > >
> > > >
> > > >
> > >
> > >
>
>