aspose file tools *
The moose likes OO, Patterns, UML and Refactoring and the fly likes Design choice for dispatching request to view Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Design choice for dispatching request to view" Watch "Design choice for dispatching request to view" New topic
Author

Design choice for dispatching request to view

Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
Hi all,
I stuck b/w 2 design choices for dispatching request to view from controller...
Choice 1
---------
Always dispatch to some template kinda view that includes header view,PWA and other required views.
Choice 2
---------
Dispatch to different views(PWA) that includes required views.
(In my implementation JSPs are used as views)
What I am intersted to know is about better choice between these two.
both choices are easy to implement..There are chances that contents in my header and other views vary but always I required views like header,footer
Any suggestions are greatly appreciated.
TIA
Manohar
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

What is PWA?


Groovy
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
Hi Pradeep,
How r u?
PWA stands for primary work area view...
TIA
Manohar
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Read this link
http://www.oreilly.com/catalog/jakarta/chapter/ch14.html

[ September 15, 2003: Message edited by: Pradeep Bhat ]
corrected URL to remove trailing slash
[ September 15, 2003: Message edited by: Frank Carver ]
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
Got error while accessing this link :-(
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

I prefer the first approach. Can you explain more about the second one, I havent undertsood it.
The URL is about apache Tiles
http://www.oreilly.com/catalog/jakarta/chapter/ch14.html
Originally posted by Manohar Karamballi:
Got error while accessing this link :-(
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
Ok,
Let me make more clearer ..
In second approach,
say after successful login I am redirecting to userhomepage which includes header,footer and contains code for displaying contents of homepage itself.
In first approach,
Irrespective of context, i redirect to some template page which includes all other pages. With refernce to above example template page includes header,footer and homepage. In some other context also it redirects to same template page which includes somecontextPWA...
Hope i am more clearer this time
Manohar
Faisal Khan
Ranch Hand

Joined: Jun 29, 2003
Posts: 285
Manohar,
I am at the same juncture as yourself. I am thinking of implementing the second option since it will allow ease of template change. In the first case, if you wish to change the layout of the page, you will need to change lots of pages, whereas in the second case, there is less maintenance in this regards.
- FK


The secret to creativity is knowing how to hide your sources.
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
Think we messed up in refferring to first and second approaches..
Let's call it as template and non template approaches.
I think u voted for template based solution.
I appreciate benefits outlined by you..
But my requirement hardly calls for change of layout.
Further my number one concern in i am redirecting to template each time and my temmplare soon becomes clumsy and difficult to read with too many condition for context checking and including required pages.
One more thing..In MVC we clearly know at controller what view we need to select and hence we can avoid storing context info by resirecting to PWA page by using non template solution.
But am looking for more concrete reason and hence I am here in forum
Thanks
Manohar
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I'm a little puzzled that you seem to only be considering purely-dynamic solutions.
What I have done successfully in the past is to do the "top and bottom" templating (the bit that's essentially the same on all the pages) at "build" time rather than at "run" time. I store just what I think you are you are calling the "work area" of the JSP in a file of some sort for each JSP, then process each of these files to make a final JSP for deployment.
If you want to be fancy you can store the information for each page together with parameters for the "top and bottom" template, and use those parameters for generating the actual JSP page:
"source"

"generated page"

Does that make sense ?
[ September 15, 2003: Message edited by: Frank Carver ]

Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
Frank,
Thanks for your reply. After seeing ur reply I learnt that template has more broader meaning...
What I understood from your reply is that an option to template either header or footer,,But i am looking solution for somewhat different thing...
My query is something like this..
In my app, to redirect to view (JSP) from controller , I can do it in two ways.
- Always redirect to mysiteTemplate.jsp that includes header.jsp,PWA.jsp and footer.jsp. Here mysiteTemplate.jsp includes differnt PWA.jsp depending upon contexts.
"OR"
- Redirect to PWA.jsp and PWA.jsp in turn includes header and footer. Here my PWA can be different on different contexts. Like it can be loginSuccess.jsp or loginFailure.jsp
Further my current requirement is such that contents of header and footer are static...consists contents like siteName and copyright notices...Need not to paramterize..
TIA
Manohar
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
why not have a bit of both?
Store the page to redirect to in a context-specific property sheet, then templatise that page for ease of maintenance.
use <jsp:include> rather than <%@ include %> so you can easily change the included pages (even if static) without having to force a recompile of the template JSPs.
You can then decide runtime not only which template to use but also change the template that you are using on the fly depending on for example language settings or other user preferences (maybe you have a specific module on the page that's only visible to certain users but not others) for individual users within a context by changing the pages that are included in the template.


42
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I still don't understand why you think you need to include the header and footer at "run time" at all. What is the advantage of either of the methods you suggest compared to generating "complete" JSP pages which include both the header and footer information before they are deployed and compiled ?
In short, why consider doing some processing to include headers and footers on every page request when you can do the same processing just once before the site is deployed?
[ September 16, 2003: Message edited by: Frank Carver ]
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Redirect to PWA.jsp and PWA.jsp in turn includes header and footer. Here my PWA can be different on different contexts. Like it can be loginSuccess.jsp or loginFailure.jsp

This looks good.
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
I still don't understand why you think you need to include the header and footer at "run time" at all.

I guess if i use @include instead of jsp:include header and footer are processed @ compile time rather than runtime...

What is the advantage of either of the methods you suggest compared to generating "complete" JSP pages which include both the header and footer information before they are deployed and compiled ?

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

TIA
Manohar
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
Hi Pradeep,
Thanks for reply...
This looks good.

Could u tell me how this approach fares better against other one?
TIA
Manohar
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
I still don't understand why you think you need to include the header and footer at "run time" at all. What is the advantage of either of the methods you suggest compared to generating "complete" JSP pages which include both the header and footer information before they are deployed and compiled ?

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

In short, why consider doing some processing to include headers and footers on every page request when you can do the same processing just once before the site is deployed?

See above. Static content often changes more quickly than the rendering of dynamic content (read carefully ).
By separating the two as much as possible any problems with static content updates requiring changes to (at least recompilation of) JSPs gets removed.
The overhead of using dynamic includes instead of static includes for static data is minimal (might even have a positive effect on performance depending on how the servlet/JSP engine handles such includes).
IMO static includes are only to be used to break up large JSPs into smaller logical units (and then only when data in each of those modules depends in some way on data in other modules), not to separate out static and dynamic data.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Could u tell me how this approach fares better against other one?

This will give you more flexibility. It is easier to change the layout in the 2nd approach than the first one. Do you agree ? (I want to make sure that I have understood your problem)
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
I feel changing layout is more easier if we use template.jsp...
But con is , template page become overloaded with too many context checkings.. (As some one suggested already we can use property file to overcome this..But we need to do that reading property file each time)..
Thing is each time we have to dispatch to template page from server side though we know the actual page to be included. Is this drawback? further If if we want to call some onload javascripts it will be difficult in template based solution...
Manohar
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Have you read the article on Tiles?
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
yeah i read it...
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
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 months
  • If done at "compilation" time the cost might be 1 second/few months or as much as 1 second/day
  • If 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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Design choice for dispatching request to view