Building high-content web applications
I've recently been tasked with rebuilding a JSP-based site using a Struts architecture. One of the issues (that I see) in the current architecture is that there are a number of JSPs with the text for the pages hard-coded in them. After re-writing this app, we plan on deploying it to 25+ customers - and we certainly don't want to have 25 different JSPs (with text) for each customer. I've proposed a database, but that might be a little resource intensive - so I'm wondering how folks have done this in the past (I'm sure it's been done before)?
Options I see are:
- A Database table with the following columns (page_id, title, content, section_id).
- Text files that are imported using <c:import url=""/>
What options have you used (feel free to add more) - if you've used the database approach - how do you define the page table? Maybe we should use the Roller way and use Velocity and OSCache.
Posted by Unknown on August 19, 2003 at 07:02 PM MDT #
Posted by Erik Hatcher on August 19, 2003 at 08:13 PM MDT #
Posted by Matt Raible on August 19, 2003 at 09:16 PM MDT #
Posted by John Cavacas on August 19, 2003 at 09:52 PM MDT #
Posted by Matt Raible on August 19, 2003 at 10:08 PM MDT #
Posted by Don Brown on August 20, 2003 at 01:43 AM MDT #
Posted by Fokko Degenaar on August 20, 2003 at 07:32 AM MDT #
Posted by Anthony Eden on August 20, 2003 at 08:16 AM MDT #
Posted by anonymous on August 20, 2003 at 09:08 AM MDT #
Posted by Brian Ewins on August 20, 2003 at 11:29 AM MDT #
Posted by anony on August 20, 2003 at 02:14 PM MDT #
Posted by Jeff Duska on August 20, 2003 at 03:10 PM MDT #
The gist of it...there are 2 entry points to rendering with a template, one from a servlet (mapped to *.htm and also used to trap 404 errors), the other in the template:insert tag. Both create a PageContext object (very like the JSP2 one) which carries request context. They both use a template repository to get the template object matching the requested path (checking file timestamps and parsing on demand).
The template is a List of 'Content' objects (these have one method, render(PageContext, TemplateRepository, ContentMap)) . Pieces marked as being library items/editable regions/urls are stored in here as NamedContent (the name is eg 'lbi:/Library/pagebody.lbi') . NamedContent renders itself by looking up a replacement in the content map, and if there isnt one, renders the content parsed from its base file. The contentmap contains replacements specified in a global replacement file (xml) as the actual text, uris to include, or bean.properties in scope; in the jsp case it also contains replacements pushed in by the template tags. This file is inside the webapp and isn't editable by the customer, since changing it will typically break all the site navigation.
In dreamweavermx you should model pages just like their exported xml, if you mean to support repeat regions and the like (much more complex). In DW4 the situation is simpler, with the most complex arrangement of templates being: a jsp based on an htm which includes an lbi inside an editable region, page based on a dwt file which may also include lbi files. If you try to implement this you'll find that parsed pages act both as a list of content (rendering them without replacements) and as a map of replacement editable regions which override their underlying template (in MX there are nested templates, so its much more obvious that you need to do this). You need to build the content map for a request by nesting the content maps of these templates.
URLContent objects are written as-is (for absolute urls and j_security_check), prefixed with the 'static site' location (for non-html/dir urls), prefixed with the 'dynamic site' location and rewritten with session id (for html/dir urls). Note all URLs are being made absolute in this process, so they can be used as templates for any page in your site.
I map the servlet to 404 because it can recognize when you tried to access a dir, and it redirects you to the welcome file (prior to servlet 2.4 there is no way to use a servlet as a welcome file). Once redirected to eg /index.html, if that file does not exist, the servlet forwards to the 'real' 404 error page (specified as an init param). You need a dummy '/index.htm' in your webapp to trigger the servlet for '/', at least on some servlet containers.
The devil is in the detail of course. And as I said, this approach works best on web 'sites' (customer drives the l+f) as opposed to web 'apps' (form follows function) where something more like Tapestry would suit you better.
Posted by Brian Ewins on August 21, 2003 at 03:59 AM MDT #
Posted by Josh Martin on June 26, 2008 at 09:24 PM MDT #
Posted by Josh Martin on June 26, 2008 at 09:25 PM MDT #
Posted by paradox1x on June 27, 2008 at 05:07 AM MDT #
Posted by Russell Scheerer on June 27, 2008 at 08:10 AM MDT #
Posted by Russell Scheerer on June 27, 2008 at 08:11 AM MDT #