JSF desing: Application with similar pages

Question

I have a design question regarding JSF. Sometimes, a web application consists of a set of pages that look basically the same but perform different operations in the background. As an example, consider Google that offers several search types (normal search, images, news, scholar, etc.). The interface is always very similar, but the search engine invoked in the background differs.
Obviously it's a bad idea to have an own search and results page for each search type, as many things remain identical, which results in intensive code replication. If one page is changed, all pages have to be changed. That's definitely not desired.
So what is the right way to overcome this problem using JSF? Of course I could write just one page and heavily use the "rendered" attributed in JSF tags (to account for the differences in the pages). I would then probably have some member "current search engine" in the backing bean and bind the action of the search button to the current search engine's search method. Whenever the search type is changed, the current search engine would point to another search engine object in the bean.
Further, the JSF navigation would probably become dependent on the state of a session bean. If I want to link to a help page, for example, a different page should be displayed for the, say, image search and the news search. The "help" button would probably just be bound to a help() method, which, depending on the current search engine, would return "help image search", "help news search", etc. Denpendent on the outcome, JSF could then navigate to the correct page.
I guess this approach would basically work. However, I see some relevant drawbacks.
1) Assume the user is in the "news search" mode. He then clicks on "image search" and then hits the back button. Now he hits the "help" button. Without further measures that allow to detect that the back button was hit, I guess, JSF would now navigate to the page "help image search" (even though the user (who sees the news search page), would expect to be taken to the "help news search" page). I expect this behaviour, since JSF (or better the backing bean) does not know that we are on the "news search" page again (as it is only a cached copy from the browser). If there were multiple pages with different URLs for each page, JSF could detect that fact but checking the viewId (is that correct?).
2) I guess the JSF pages become rather difficult to read (and thus to edit) due to the extensive use of rendered and unrendered parts.
I guess the first problem could be solved with some hidden inputs on the pages (that inform the backing bean about the page we are currently viewing). But this rather looks like a hack to me...
Therefore my question. Is there some nice way to write a JSF application with these characteristics? And if yes, how should it be done? Maybe there is something like inheritance and the ability to override certain parts (as in object oriented programming). Then I could keep different pages (with own URLs), but don't have to replicate the code.
And ideas, hints and links to documents and discussions about that topic are highly appreciated.
Thanks,
Michael

Answer 1

According the contents, I can't use JSF alone to deal
big projects, have to associate with a framework. IF
it is the case, I don't think it's an easy choice for
new user, though it has great flexibility for the
others.additional application framework helps you to separate functional and behavioural aspects of your system. it helps by providing standarised way of dealing with the separation. if you clearly design your own rules - you don't have to use additional 'big' framework. however, it might be usefull to use some smaller specialised ones, eg. for tiles or validation, if it's an issue in your particular case.
that's my opinion.
Any sugestion if there is a common appoarch that JSF
doesn't have to associate with a framework (maybe in
the near future)?now i'm working on portal application. it's build of rather small portlets, each one implemented using jsf. we doesn't use any additional frameworks. it wouldn't make much sense, as the portlet-based architecture enforces clear and distinct separation of functional modules.
wojtek