myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ernst Fastl" <>
Subject Re: Option for NavigationHandler to support viewIds as outcome
Date Tue, 31 Oct 2006 08:29:53 GMT
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



On 10/30/06, Matthias Wessendorf <> 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 <> wrote:
> >
> >
> > On 10/30/06, Mario Ivankovits <> 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
> further stuff:
> blog:
> mail: mwessendorf-at-gmail-dot-com

View raw message