I am really fine with adding this NH_Impl to Tomahawk. Here are my rules for that: -It is not used by default! -it is not configured to a bogus web.xml context param -it should be used in the app's faces-cfg.xml file
the cons and pros are like "Do you like Rails, or not" :) Well, somethimes that makes sense; sometimes not. The fun is, that you can choose! Just put it to your faces-cfg. I have heard that "requirement" before that thread. I don't think it's a not understanding JSF thing. Sorta lazy guy approach ... -M On 10/30/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 10/30/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > In reality there is a dependency between two pages, there is a "silent" > contract how to prepare the managed beans so that the destination page > knows what to display (and I think the f:param stuff is useless here). > So more often than not you'll use a updateActionListener to set stuff on > the destination backing bean. And voilla, you'll have hard dependency > between these two pages. This is an important point, no matter how you architect your navigation. <shameless-plug> That is why Shale's view controller has a prerender() method ... you are encouraged to use that method in the "destination" page to pull data that this page needs out of the model, rather than having the "origin" page push data into the destination page (or some request scoped objects whose names are known to both). That way, coupling is minimized to something like passing primary keys -- and I like the convention of always passing, say, a customerId, in the same place throughout the application (independent of particular pages), to minimize direct coupling between any two particular pages. This approach also makes it *much* easier for your application to support bookmarkable GET URLs that pass primary keys with request parameters. </shameless-plug> Craig
-- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
