Manohar Karamballi wrote;
Here i am not getting what generating "complete" jsp page means? How I can have separate JSPs for header and footer that could be included in every required page before they compiled??? Are u trying to tell duplicating header and footer stuff in each page...? think ur trying to tell something else..pls clarify..As far as I know ttwo ways of including is using @include and jsp:include..one @ compile time and other @ run time I'll try and rephrase. My suggestion is to keep and edit the various component parts of your page (header, footer, body text etc.) separately, then process them into complete pages (for example, by adding the standard headers and footers to each page) before the pages are deployed to the server. I usually do this under the control of the same
Ant build script which assembles the JSPs and
servlets into a deployable war file.
Note particularly that this is
not done using @include (which takes place at the time the JSP is compiled on the server) or jsp:include (which takes place at the time the JSP is requested by the browser). By the time the JSP is compiler and requested, the adding of the header and footer have already been done. This transformation is done on the development machine, before the files are deployed to the server
Jeroen Wenting wrote:
Flexibility. The idea is to have as little hardcoded into the JSP as possible, ideally relegating it to the task of rendering the dynamic content only. By using static includes you still effectively hardcode non-dynamic data into the JSP causing any changes to that data (like a different layout of that header) to cause the JSP to have to be recompiled. Depending on the frequency of changes that might be acceptable but it is inflexible and a potential cause for frustration especially if the static HTML is maintained by others (who will of course fail to notify you of their changes and then scratch their heads in confusion when they are not visible).
...
Static content often changes more quickly than the rendering of dynamic content. This an interesting point. I won't disagree that it may be the case in your situation, but I have never personally worked on a situation where "static" headers and footers changed more often than changes to the JSPs, servlets, resources or other "dynamic" parts of the web application.
Even in situations where a third party is responsible for changes to such included material, I'd still consider my style of pre-prpocessing step. You'd just need a prominent "button" which enabled people to regenerate and republish any pages which depend on the "static" content.
My logic for suggesting this approach is based on the accumulated "cost" (in terms of time and processing power) of any kind of page transformation, including dynamic inclusion. Let's consider a typical (in my experience) web application.
"Style" changes (typically to headers/footers but sometimes also affecting actual page content) might happen at most every few months as the corporate image makers decide on another re-branding exercise."Behaviour" changes (code changes to shared classes, servlets, custom tags or JSP scriptlets) might happen each release of the application, say at most every few weeks."Server" changes happen each time the server is restarted or the application is reloaded. Many companies I have worked with have a policy of restarting each server once a day or once every week."Content" changes might happen (depending on the application) each time a new message is added to a bulletin board, each time a new item is added to a catalogue etc. (say at most several times an hour)"Session" changes might happen each time someone logs on or off (maybe every few minutes)"Request" changes are ones which happen each time a page is returned to a browser (on a busy site, many times a second) Pre=processed page templating happens with every style or behaviour change.Page compilation/loading and "@include" happens with every behaviour change and maybe every server change.Dynamic content generation and "jsp:include" happens with every request change. So, if adding the page header and footer takes (say) 1 second (probably exaggerated):
If done at "pre-processing" time the cost is 1 second/few monthsIf done at "compilation" time the cost might be 1 second/few months or as much as 1 second/dayIf done at "request" time the cost might be 1 second several times a second. In general, the earlier each bit of processing can be done in the process, the less time and processor power it costs, and therefore the less it impacts user response times, and the less the server hardware needs to cost.
Some major sites have such a high ratio of requests to content changes, that they regenerate a completely static site (pure, pre-processed HTML, no JSP or servlets, no dynamically served pages) each time the content is added, several times a day. the main server is optimised to serve purely static content, and does not need a
Java runtime, or any other server-side overhead.
All this may still be inappropriate to your use, but I hope it is now at least a little clearer.