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
> > > >
> > > >
> > > >
> > >
> > >
> 
> 

Reply via email to