Hi again, Thank you very much for your opinions and insights. I understand now that there are doubts supporting such a feature. What I understood these are mainly about encouraging users to use "not best practise" approaches. IMO this is for sure a duty of teachers or books, but a webdevelopment framework? I'm not so sure about that. I think users should be provided with as much flexibility as possible rather than trying to force them to share all our philosophy.
And also this is as martin and mattias pointed out usable in small scale applications tiny prototypes and so on. Seeing competitions as ruby on rails and php features like that could make JSF also more attractive for prototyping. But thats just my opinion and I'm for sure not starting to do something not approved by the community again. So what is the desicion? 1.) Seperate NavigationHandlerImpl 2.) Configurable Option 3.) Custom NH code in the wiki with a "discouraged" note 4.) Not at all regards Ernst On 10/30/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
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
