RE: Standar Template
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: Noo - 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
RE: Standar Template
Oops. Sorry everyone, that was not supposed to be posted to the list. Jeff -Original Message- From: Jeff Schnitzer Sent: Thursday, May 17, 2001 8:47 PM To: Orion-Interest Subject: RE: Standar Template 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: Noo - 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
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: Noo - 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
RE: Standar Template
Maybe you could use a filter? Check out the filter tutorial at http://www.orionserver.com/ /Jason -Original Message- From: Dave Ford [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 9: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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
Re: Standar Template
Dave, why are you resending this to the Orion-Interest list? You've seen a few ways to do it - a bad suggestion to use XSLT on every page, plus SiteMesh, plus a few others. Read the responses, mmmkay? On Thu, 10 May 2001, Dave Ford wrote: 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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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 --- Joseph B. Ottinger [EMAIL PROTECTED] http://winter.ajacency.com/ IT Consultant
Re: Standar Template
Using a filter sounds like a good idea. It is a natural way to implement Decorator design pattern. -- Joni [EMAIL PROTECTED] Smith Jason wrote: Maybe you could use a filter? Check out the filter tutorial at http://www.orionserver.com/ /Jason -Original Message- From: Dave Ford [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 9: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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
Re: Standar Template
From his message headers it looks like it spent a *long* time in a mail queue. I'd guess the original did the same and he assumed it'd been lost. We have no performance problems with precompiled XSLT on every page; perhaps you should reconsider your opinion. We're even using xalan, reportedly just about the slowest xslt processor around... Kirk Yarina somewhat trimmed: Received: from druid.evermind.net ... Fri, 11 May 2001 13:36:06 -0100 Received: from win2kweb ... Fri, 11 May 2001 14:14:30 -0400 Received: from itreya ... Fri, 11 May 2001 07:15:17 -0400 Received: from mail.itreya. ... Fri, 11 May 2001 16:54:26 +0530 Received: from apache ... Thu, 10 May 2001 15:23:56 -0400 At 09:12 AM 5/11/01 -0500, you wrote: Dave, why are you resending this to the Orion-Interest list? You've seen a few ways to do it - a bad suggestion to use XSLT on every page, plus SiteMesh, plus a few others. Read the responses, mmmkay? On Thu, 10 May 2001, Dave Ford wrote: 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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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 --- Joseph B. Ottinger [EMAIL PROTECTED] http://winter.ajacency.com/ IT Consultant
RE: Standar Template
Consider SiteMesh a prebuilt filter for the purpose of implementing HTML decorators ;) Trust me - try it! -mike Mike Cannon-Brookes - Founder, Core Developer OpenSymphony - http://www.opensymphony.com The Open Source J2EE Component Project Latest News - Cache in on faster, more reliable JSPs http://www.javaworld.com/javaworld/jw-05-2001/jw-0504-cache.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joni Suominen Sent: Saturday, May 12, 2001 12:26 AM To: Orion-Interest Subject: Re: Standar Template Using a filter sounds like a good idea. It is a natural way to implement Decorator design pattern. -- Joni [EMAIL PROTECTED] Smith Jason wrote: Maybe you could use a filter? Check out the filter tutorial at http://www.orionserver.com/ /Jason -Original Message- From: Dave Ford [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 9: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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
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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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
RE: Standar Template
Noo - 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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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
Re: Standar Template
Dan, Take a look at this article: http://developer.java.sun.com/developer/technicalArticles/javaserverpages/js p_templates/ I think it provides a solution you should consider. I've built my own version of the taglib (I wanted default values for the parameters) and it works well. Regards, Gordon. -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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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 tdjsp:include page=standardHeader.jsp//td /tr tr td colspan=2 table tr td valign=topjsp: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
