Option for NavigationHandler to support viewIds as outcome

[Ernst Fastl <er...@gmail.com>]

Hi!

At the moment when no navigation case for an outcome is found
the navigationHandler decides to stay at the same view. I think
an option for web.xml would be useful to tell the navigationHandler
if no navigation case for an outcome is found, but the outcome
matches a viewId to navigate to this view id.

This idea was mainly driven by a lot of jsf-projects where I saw for each
view id:

<navigation-rule>
        <from-view-id>*</from-view-id>
        <navigation-case>
            <from-outcome>viewId</from-outcome>
            <to-view-id>/viewId.xhtml</to-view-id>
            <redirect/>
        </navigation-case>
...


which seems kind of unnecessary to me

what do you think about that?

regards

Ernst

Re: Option for NavigationHandler to support viewIds as outcome

[Sean Schofield <se...@gmail.com>]

I think we should be very careful about adding a feature that
encourages people to drift away from the spec.  I agree with the
reasons that Craig laid out for why the outcomes behave the way they
do now.

Its true that its not our job to force people to do follow certain
standards.  Its also true that we shouldn't be putting code into a
shared codebase that serves the needs of a minority of the
participants.  I am not hearing a lot of enthusiastic support for this
idea.  Reactions are ranging from "as long as its optional" to "this
has no place in JSF."

I think we should keep this out of Tomahawk.  People are free to do
whatever they want with their own code so this seems to be a case
where that is most appropriate.  Use it in your personal code and
writeup a wiki or blog entry on it if you want to share it.  Not
everything has to make it in and it seems like enough people have
reservations about it.

My .02

Sean



On 10/31/06, Matthias Wessendorf <ma...@apache.org> wrote:
> On 10/31/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> > > 1.) Seperate NavigationHandlerImpl
> > IMHO, this is a must! I think we should *not* implement stuff which
> > "silently" changes/enhances the behaviour - especially in myfaces-impl!!
> > The TCK might forbid this change anyway ...
>
> +1 !
>
>
> > > 2.) Configurable Option
> > not required, as everyone can configure this NH in faces-config.xml.
>
> right! adding stuff to the web.xml for that is blech!
>
> > > 3.) Custom NH code in the wiki with a "discouraged" note
> > This might be a good compromise.
>
> like we do with the JBoss stuff ?
> I don't mind that
>
> > >
> > > 4.) Not at all
> > I do not mind ;-)
> >
> >
> > 5) Add the new NH to the sandbox (but not configured by default)
> >
> > I like it to put stuff to the sandbox first and see if the community is
> > willing to use them .... something like "the time will tell if its worth".
>
> Yes, my understanding is that EVERY new Tomahawk stuff goes to Sandbox first.
> Components AND framework features.
>
> Go ahead Ernstl
>
> -M
>
> > Ciao,
> > Mario
> >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>

Re: Option for NavigationHandler to support viewIds as outcome

[Matthias Wessendorf <ma...@apache.org>]

On 10/31/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > 1.) Seperate NavigationHandlerImpl
> IMHO, this is a must! I think we should *not* implement stuff which
> "silently" changes/enhances the behaviour - especially in myfaces-impl!!
> The TCK might forbid this change anyway ...

+1 !


> > 2.) Configurable Option
> not required, as everyone can configure this NH in faces-config.xml.

right! adding stuff to the web.xml for that is blech!

> > 3.) Custom NH code in the wiki with a "discouraged" note
> This might be a good compromise.

like we do with the JBoss stuff ?
I don't mind that

> >
> > 4.) Not at all
> I do not mind ;-)
>
>
> 5) Add the new NH to the sandbox (but not configured by default)
>
> I like it to put stuff to the sandbox first and see if the community is
> willing to use them .... something like "the time will tell if its worth".

Yes, my understanding is that EVERY new Tomahawk stuff goes to Sandbox first.
Components AND framework features.

Go ahead Ernstl

-M

> Ciao,
> Mario
>
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Option for NavigationHandler to support viewIds as outcome

[Martin Marinschek <ma...@gmail.com>]

As an outcome of this discussion, I'm +1 for 1.

regards,

Martin

On 10/31/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > 1.) Seperate NavigationHandlerImpl
> IMHO, this is a must! I think we should *not* implement stuff which
> "silently" changes/enhances the behaviour - especially in myfaces-impl!!
> The TCK might forbid this change anyway ...
>
> > 2.) Configurable Option
> not required, as everyone can configure this NH in faces-config.xml.
>
> > 3.) Custom NH code in the wiki with a "discouraged" note
> This might be a good compromise.
>
> >
> > 4.) Not at all
> I do not mind ;-)
>
>
> 5) Add the new NH to the sandbox (but not configured by default)
>
> I like it to put stuff to the sandbox first and see if the community is
> willing to use them .... something like "the time will tell if its worth".
>
>
> Ciao,
> Mario
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Option for NavigationHandler to support viewIds as outcome

[Matthias Wessendorf <ma...@apache.org>]

> > > 2.) Configurable Option
> > not required, as everyone can configure this NH in faces-config.xml.
>
> In particular, if you decide to implement this feature, consider packaging
> it inside a separate JAR file with its own embedded META-INF/faces-
> config.xml file that defines the custom navigation handler.  That way, it is
> self configuring -- to use the feature, just drop the JAR into your app.

You are right with that (that also what you do in Shale - Tiles for instance).
Shale Tiles is different. It makes sense in that world to do that.

For this NH, we should ensure to have it not that convenient to get it working.
They should need to put it manually in their faces-cfg.xml, to be
aware they know
what they are doing. By adding random-myfaces-xxx jars you can cause
confusion to the users. Adding it to the faces-cfg.xml is sorta
"marker interfaces" pattern (sure a poor one :))

Thanks!
Matt


> Craig
>
> > > 3.) Custom NH code in the wiki with a "discouraged" note
> > This might be a good compromise.
> >
> > >
> > > 4.) Not at all
> > I do not mind ;-)
> >
> >
> > 5) Add the new NH to the sandbox (but not configured by default)
> >
> > I like it to put stuff to the sandbox first and see if the community is
> > willing to use them .... something like "the time will tell if its worth".
> >
> >
> > Ciao,
> > Mario
> >
> >
>
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Option for NavigationHandler to support viewIds as outcome

[Craig McClanahan <cr...@apache.org>]

On 10/31/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi!
> > 1.) Seperate NavigationHandlerImpl
> IMHO, this is a must! I think we should *not* implement stuff which
> "silently" changes/enhances the behaviour - especially in myfaces-impl!!
> The TCK might forbid this change anyway ...
>
> > 2.) Configurable Option
> not required, as everyone can configure this NH in faces-config.xml.


In particular, if you decide to implement this feature, consider packaging
it inside a separate JAR file with its own embedded META-INF/faces-
config.xml file that defines the custom navigation handler.  That way, it is
self configuring -- to use the feature, just drop the JAR into your app.

Craig

> 3.) Custom NH code in the wiki with a "discouraged" note
> This might be a good compromise.
>
> >
> > 4.) Not at all
> I do not mind ;-)
>
>
> 5) Add the new NH to the sandbox (but not configured by default)
>
> I like it to put stuff to the sandbox first and see if the community is
> willing to use them .... something like "the time will tell if its worth".
>
>
> Ciao,
> Mario
>
>

Re: Option for NavigationHandler to support viewIds as outcome

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> 1.) Seperate NavigationHandlerImpl
IMHO, this is a must! I think we should *not* implement stuff which
"silently" changes/enhances the behaviour - especially in myfaces-impl!!
The TCK might forbid this change anyway ...

> 2.) Configurable Option
not required, as everyone can configure this NH in faces-config.xml.

> 3.) Custom NH code in the wiki with a "discouraged" note
This might be a good compromise.

>
> 4.) Not at all
I do not mind ;-)


5) Add the new NH to the sandbox (but not configured by default)

I like it to put stuff to the sandbox first and see if the community is
willing to use them .... something like "the time will tell if its worth".


Ciao,
Mario

Re: Option for NavigationHandler to support viewIds as outcome

[Ernst Fastl <er...@gmail.com>]

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 <ma...@apache.org> 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 <cr...@apache.org> wrote:
> >
> >
> > On 10/30/06, Mario Ivankovits <ma...@ops.co.at> 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
>

Re: Option for NavigationHandler to support viewIds as outcome

[Matthias Wessendorf <ma...@apache.org>]

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 <cr...@apache.org> wrote:
>
>
> On 10/30/06, Mario Ivankovits <ma...@ops.co.at> 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

Re: Option for NavigationHandler to support viewIds as outcome

[Craig McClanahan <cr...@apache.org>]

On 10/30/06, Mario Ivankovits <ma...@ops.co.at> 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

Re: Option for NavigationHandler to support viewIds as outcome

[Martin Marinschek <ma...@gmail.com>]

Hi Mario,

well, the question is if we find a good convention-over-configuration
approach, and the discussion really boils down to your remark about
whether you can derive the view-id from the outcome nicely. Good
point. Ernst?

regards,

Martin

On 10/30/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > 1) I have a managed-bean action-method which returns "overview" and
> > this means, I'll go to overview.jsp
> As long as you placed all your jsps in the root of your webapp this
> works nicely, you can check if there is a navigation rule and - if not,
> simply add .jsp and move to this view.
> But if you have a directory structure (like we have) things start to be
> not that nicely anymore, then you have to return something like
> "/my/view/dir/abc". You'll have to create a navigation rule with outcome
> "/my/view/dir/abc" .... this is not really nice.
> Maybe we can overcome this with an configurable
> "NavigationNameExtractor" which takes the last token of your view-Id to
> lookup a navigation rule.
>
> But, to say the truth, even in an small application I wont use such a
> NavigationHandler. I like the decoupling of navigation and destination
> view too, THOUGH, I dont think that this decoupling allows someone to
> change the navigation "on the fly".
>
> 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.
>
> Using a dialog or conversation scope here wont help much as the
> destination page (e.g. a search page) might participate in many
> different dialog or conversation scopes.
>
> At least, the "replaced destination view" has to use the same bean (or
> call it interface in this context) to determine which data to display.
>
>
> Said that, I wont use this new NavigationHandler, but I don't mind if we
> add it.
>
> Ciao,
> Mario
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Option for NavigationHandler to support viewIds as outcome

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> 1) I have a managed-bean action-method which returns "overview" and
> this means, I'll go to overview.jsp
As long as you placed all your jsps in the root of your webapp this
works nicely, you can check if there is a navigation rule and - if not,
simply add .jsp and move to this view.
But if you have a directory structure (like we have) things start to be
not that nicely anymore, then you have to return something like
"/my/view/dir/abc". You'll have to create a navigation rule with outcome
"/my/view/dir/abc" .... this is not really nice.
Maybe we can overcome this with an configurable
"NavigationNameExtractor" which takes the last token of your view-Id to
lookup a navigation rule.

But, to say the truth, even in an small application I wont use such a
NavigationHandler. I like the decoupling of navigation and destination
view too, THOUGH, I dont think that this decoupling allows someone to
change the navigation "on the fly".

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.

Using a dialog or conversation scope here wont help much as the
destination page (e.g. a search page) might participate in many
different dialog or conversation scopes.

At least, the "replaced destination view" has to use the same bean (or
call it interface in this context) to determine which data to display.


Said that, I wont use this new NavigationHandler, but I don't mind if we
add it.

Ciao,
Mario

Re: Option for NavigationHandler to support viewIds as outcome

[Arash Rajaeeyan <ar...@gmail.com>]

Hi Martin,
First thanks for taking time and answering me.
Believe me or not, the concept is hard to grasp for lots of developers, at
least for people in my country who are not as wise and intelligent as people
in Germany and Austria, lots of developers are not Computer Science PHD and
most of them are not even college educated!

I remember 10 years ago, when we were developing codes in C++, most of our
time was spend on finding memory problems caused by illegal pointers created
by freeing an object in wrong places. Now with garbage collection in java it
is years that I haven't seen the problem, although average knowledge of
developers is much lower now because of high demand in IT industry.

May be this phrase is wrong, but it think a good development framework
(especially those who are designed for ease of use) should not let
developers make mistakes.I remember when I was in guidance primary school,
our Pascal and C programming teacher decided not to teach us about Labels,
because he knew that some of us had some experience in GW-Basic programming
and we can't get ride of GOTO, and we can't ever learn structured
programming, now I think the same case is about this NavigationHandler
mechanism, it is like goto in structured languages.

Regards
Arash
On 10/30/06, Martin Marinschek <ma...@gmail.com> wrote:
>
> Hi Arash,
>
> I don't think we're in the JSF space to force developers to do
> something in a certain way. The navigation system of JSF is good, it's
> been devised with decoupling in mind, and you might want or not want
> that for your application - I don't think that the rationale behind
> this is hard to grasp for anyone. So your sentence about the "deep
> rationality behind the navigation mechanism" is a bit overblown...
> Especially, as with what Ernst suggested, you can still configure -
> you just don't have to!
>
> There is a host of web-frameworks which don't build on this decoupling
> out of the box - so why not giving the developer the option to do
> things in the way they're used to? Mind it, I'm not one of the guys
> who hate configuration files, and I don't have anything against
> faces-config.xml. There are people out there who want to reduce it to
> a bare minimum, though, and I don't see why one shouldn't.
>
> Enough said, there are pro's and con's, and I do believe that an
> option won't hurt anyone, if it's nicely implemented.
>
> regards,
>
> Martin
>
> On 10/30/06, Arash Rajaeeyan <ar...@gmail.com> wrote:
> > Hi Martin,
> > may be this feature is very good for highly professional developer like
> you,
> > but consider those developers new in JSF.
> >
> > what is the different between this and using forward and redirect
> methods,
> > from developer point of view? (not considering JSF life cycle problems)
> >
> > (if a developer uses forward and direct, then s/he is not even forced to
> > define a view for their page in facesconfig file! and he can use the
> same
> > methods he may already know from JSP/ Servlet)
> >
> > I have seen lots of .net and JSP developers who were trying to use
> > navigation rules just the way as redirects. and complaining about how
> hard
> > is it in JSF to redirect into another page, (complex methods), I think
> this
> > is just as Craig says because they haven't understand the deep
> rationality
> > behind navigation mechanism yet, and this feature will help them never
> > understand it!
> >
> >
> > On 10/30/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > Hi David,
> > >
> > > @breaking tool support: yes, that's true, and is something that might
> > > or might not be of interest to developers.
> > >
> > > @application size: For an application with 2000 views, we're
> > > definitely talking about large-size here. I'm absolutely d'accord that
> > > for a large size applications with a high number of developers
> > > assigned to them the normal navigation system should be used.
> > >
> > > Having the option of not using the default navigation system for
> > > small, simple applications is something positive, though.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 10/30/06, David Chandler <da...@learnjsf.com> wrote:
> > > > Don't forget that returning view IDs in outcomes will break tool
> support
> > > > such as the visual page flow designer in Exadel Studio. Even without
> > tools,
> > > > I find it extremely helpful as a developer to be able to look in one
> > place
> > > > to see how the application flows. The proposed capability would make
> > that
> > > > impossible, so I agree with Craig and Arash that returning view IDs
> in
> > > > outcomes is unsuitable for apps that will be maintained by multiple
> > > > developers.
> > > >
> > > > Having worked as one of 30+ developers on a large application (2000
> > views)
> > > > written in a scripting language that effectively returned view IDs
> in
> > > > outcomes, I can testify to the horrors of code maintenance with this
> > > > approach. Introducing finite state machine navigation into that code
> > base
> > > > and moving nav rules to config files has made it much easier to work
> on.
> > > >
> > > > David Chandler
> > > > JSF Consultant / Trainer
> > > > learnjsf.com
> > > >
> > > >
> > > > On 10/30/06, Arash Rajaeeyan < arash.rajaeeyan@gmail.com> wrote:
> > > > > It is much easier for a developer (especially if they are
> beginners in
> > > > JSF) to return name of the page instead of event occurred in page
> > (logical
> > > > outcome) as output.
> > > > >
> > > > >
> > > > > There are some bad development practices, which when a developer
> get
> > used
> > > > to them, it is hard to forget, I think this feature is one of them.
> > > > >
> > > > > since this bad practice(same reasons as described by Craig), makes
> > life
> > > > easier for them, when they have this feature they will get addicted
> to
> > it,
> > > > and they won't learn the real idea behind outcomes.
> > > > >
> > > > >
> > > > > I think this is like giving marijuana to JSF developers! Like the
> > cartoon
> > > > in the theserverside.com about AOP considered harmful ;-) Regards
> > > > > Arash
> > > > >
> > > > >
> > > > >
> > > > > On 10/30/06, Martin Marinschek < martin.marinschek@gmail.com>
> wrote:
> > > > > > Hi Craig,
> > > > > >
> > > > > > It's all about convention over configuration, and this concept
> is in
> > > > > > turn very good for maintenance. Writing unnecessary
> configuration
> > code
> > > > > > isn't.
> > > > > >
> > > > > > Let's look at an automatic navigation handler in practice:
> > > > > >
> > > > > > 1) I have a managed-bean action-method which returns "overview"
> and
> > > > > > this means, I'll go to overview.jsp
> > > > > >
> > > > > > 2) I want to change this to go to "overview_2.jsp"
> > > > > >
> > > > > > 3) so I won't change anything in the managed-bean-method, but
> create
> > a
> > > > > > new navigation-rule (in your case, I'd need to change the
> > > > > > navigation-rule - where is the maintenance difference, I don't
> touch
> > > > > > my managed-bean?)
> > > > > >
> > > > > > 4) If I want to go to somewhere else from any other page, I'll
> need
> > to
> > > > > > create additional navigation-rules, according to the concept of
> JSF.
> > > > > >
> > > > > > Essence is - you don't have to change anything in your managed
> bean,
> > > > > > you  just add configuration rules where necessary, but keep them
> out
> > > > > > where unnecessary.
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 10/30/06, Craig McClanahan < craigmcc@apache.org > wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 10/30/06, Martin Marinschek < martin.marinschek@gmail.com>
> > wrote:
> > > > > > > > Hi Craig,
> > > > > > > >
> > > > > > > > you have been argumenting into this direction before, and
> I'm
> > sorry
> > > > to
> > > > > > > > disagree completely. What JSF does in the standard is good
> for
> > > > > > > > projects where you have this necessity of different roles
> for
> > page
> > > > > > > > development and back-end development.
> > > > > > >
> > > > > > > It's not a matter of different roles.  The design principles I
> > > > advocate are
> > > > > > > the same whether there is one developer performing multiple
> roles,
> > or
> > > > > > > different developers (or developer groups) performing the
> > different
> > > > roles.
> > > > > > >
> > > > > > > The architectural issues here are exactly the same in either
> case.
> > > > > > >
> > > > > > > > Generally - for small projects, and the majority of
> web-projects
> > are
> > > > > > > > still small projects, the person writing the
> navigation-handling
> > > > code,
> > > > > > > > the page, and the backing-bean will be the same, so why not
> give
> > > > them
> > > > > > > > the ability to have a convention-over-configuration
> approach?
> > You
> > > > can
> > > > > > > > always override convention-over-configuration by supplying
> > > > > > > > configuration!
> > > > > > >
> > > > > > > Because that user will be crying alligator tears a year from
> now,
> > or a
> > > > month
> > > > > > > from now, when the person responsible for the overall
> organization
> > of
> > > > the
> > > > > > > webapp changes the set of view identifiers that represents the
> UI
> > of
> > > > an app.
> > > > > > >  WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS
> LOGIC???.  That
> > is a
> > > > > > > cross-linkage between view tier and model tier that I find
> > > > unacceptable in
> > > > > > > large scale apps.
> > > > > > >
> > > > > > > You have a seductive argument with respect to small scale
> apps.
> > But I
> > > > can
> > > > > > > tell you from 30 years of professional software development
> > experience
> > > > that
> > > > > > > managers tend to buy in to this kind of attitude at the
> prototype
> > > > stage,
> > > > > > > when ongoing application maintenance is not a
> consideration.  And
> > > > those
> > > > > > > types of people tend to be really unhappy when the effects of
> this
> > > > type of
> > > > > > > decision cause their maintenance budgets to skyrocket.  The
> scale
> > of
> > > > the app
> > > > > > > does not actually matter -- the percentage of the overall
> budget
> > that
> > > > must
> > > > > > > be allocated to reworking previously running code is *always*
> a
> > major
> > > > > > > consideration.
> > > > > > >
> > > > > > > > Furthermore, I seem to resemble that in the discussion about
> > > > > > > > annotations you've made the same proposal as Ernst has at
> the
> > > > > > > > beginning of this discussion - writing a custom
> > navigation-handler
> > > > > > > > which enables one to optionally not configure navigations,
> and
> > not
> > > > > > > > handle navigation via annotations.
> > > > > > >
> > > > > > > I am *adamantly* in the "no annotations for navigaiton" camp
> ...
> > > > navigation
> > > > > > > is absolutely *not* something that should be done with
> > annotations.
> > > > Doing
> > > > > > > so would have the same effect as implementing the suggested
> > approach
> > > > -- it
> > > > > > > would be requiring the person developing the server side
> business
> > > > logic to
> > > > > > > be intimately aware of view tier considerations like "what
> view
> > should
> > > > I
> > > > > > > show next?".
> > > > > > >
> > > > > > > Doing so makes it basically impossible to reuse business logic
> in
> > > > scenarios
> > > > > > > like:
> > > > > > >
> > > > > > > * Migrating a non-AJAX app to be AJAX-enabled
> > > > > > >
> > > > > > > * Using the same business logic for REST-based or SOAP-based
> > > > > > >   web services
> > > > > > >
> > > > > > > In short, I believe that requiring the developer of an action
> > method
> > > > to know
> > > > > > > anything about what the view tier will do next is a ***very***
> bad
> > > > idea.
> > > > > > >
> > > > > > > You might note that the Shale Tiger Extensions have no
> provision
> > for
> > > > > > > annotation based navigation.  That is a deliberate design
> choice,
> > not
> > > > one
> > > > > > > based on limited development time :-)
> > > > > > >
> > > > > > > > regards,
> > > > > > > >
> > > > > > > > Martin
> > > > > > >
> > > > > > >
> > > > > > > Craig
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > http://www.irian.at
> > > > > >
> > > > > > Your JSF powerhouse -
> > > > > > JSF Consulting, Development and
> > > > > > Courses in English and German
> > > > > >
> > > > > > Professional Support for Apache MyFaces
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Arash Rajaeeyan
> > > >
> > > >
> > > >
> > > > --
> > > > http://learnjsf.com
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
> >
> >
> > --
> > Arash Rajaeeyan
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: Option for NavigationHandler to support viewIds as outcome

[Martin Marinschek <ma...@gmail.com>]

Hi Arash,

I don't think we're in the JSF space to force developers to do
something in a certain way. The navigation system of JSF is good, it's
been devised with decoupling in mind, and you might want or not want
that for your application - I don't think that the rationale behind
this is hard to grasp for anyone. So your sentence about the "deep
rationality behind the navigation mechanism" is a bit overblown...
Especially, as with what Ernst suggested, you can still configure -
you just don't have to!

There is a host of web-frameworks which don't build on this decoupling
out of the box - so why not giving the developer the option to do
things in the way they're used to? Mind it, I'm not one of the guys
who hate configuration files, and I don't have anything against
faces-config.xml. There are people out there who want to reduce it to
a bare minimum, though, and I don't see why one shouldn't.

Enough said, there are pro's and con's, and I do believe that an
option won't hurt anyone, if it's nicely implemented.

regards,

Martin

On 10/30/06, Arash Rajaeeyan <ar...@gmail.com> wrote:
> Hi Martin,
> may be this feature is very good for highly professional developer like you,
> but consider those developers new in JSF.
>
> what is the different between this and using forward and redirect methods,
> from developer point of view? (not considering JSF life cycle problems)
>
> (if a developer uses forward and direct, then s/he is not even forced to
> define a view for their page in facesconfig file! and he can use the same
> methods he may already know from JSP/ Servlet)
>
> I have seen lots of .net and JSP developers who were trying to use
> navigation rules just the way as redirects. and complaining about how hard
> is it in JSF to redirect into another page, (complex methods), I think this
> is just as Craig says because they haven't understand the deep rationality
> behind navigation mechanism yet, and this feature will help them never
> understand it!
>
>
> On 10/30/06, Martin Marinschek <ma...@gmail.com> wrote:
> > Hi David,
> >
> > @breaking tool support: yes, that's true, and is something that might
> > or might not be of interest to developers.
> >
> > @application size: For an application with 2000 views, we're
> > definitely talking about large-size here. I'm absolutely d'accord that
> > for a large size applications with a high number of developers
> > assigned to them the normal navigation system should be used.
> >
> > Having the option of not using the default navigation system for
> > small, simple applications is something positive, though.
> >
> > regards,
> >
> > Martin
> >
> > On 10/30/06, David Chandler <da...@learnjsf.com> wrote:
> > > Don't forget that returning view IDs in outcomes will break tool support
> > > such as the visual page flow designer in Exadel Studio. Even without
> tools,
> > > I find it extremely helpful as a developer to be able to look in one
> place
> > > to see how the application flows. The proposed capability would make
> that
> > > impossible, so I agree with Craig and Arash that returning view IDs in
> > > outcomes is unsuitable for apps that will be maintained by multiple
> > > developers.
> > >
> > > Having worked as one of 30+ developers on a large application (2000
> views)
> > > written in a scripting language that effectively returned view IDs in
> > > outcomes, I can testify to the horrors of code maintenance with this
> > > approach. Introducing finite state machine navigation into that code
> base
> > > and moving nav rules to config files has made it much easier to work on.
> > >
> > > David Chandler
> > > JSF Consultant / Trainer
> > > learnjsf.com
> > >
> > >
> > > On 10/30/06, Arash Rajaeeyan < arash.rajaeeyan@gmail.com> wrote:
> > > > It is much easier for a developer (especially if they are beginners in
> > > JSF) to return name of the page instead of event occurred in page
> (logical
> > > outcome) as output.
> > > >
> > > >
> > > > There are some bad development practices, which when a developer get
> used
> > > to them, it is hard to forget, I think this feature is one of them.
> > > >
> > > > since this bad practice(same reasons as described by Craig), makes
> life
> > > easier for them, when they have this feature they will get addicted to
> it,
> > > and they won't learn the real idea behind outcomes.
> > > >
> > > >
> > > > I think this is like giving marijuana to JSF developers! Like the
> cartoon
> > > in the theserverside.com about AOP considered harmful ;-) Regards
> > > > Arash
> > > >
> > > >
> > > >
> > > > On 10/30/06, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > > Hi Craig,
> > > > >
> > > > > It's all about convention over configuration, and this concept is in
> > > > > turn very good for maintenance. Writing unnecessary configuration
> code
> > > > > isn't.
> > > > >
> > > > > Let's look at an automatic navigation handler in practice:
> > > > >
> > > > > 1) I have a managed-bean action-method which returns "overview" and
> > > > > this means, I'll go to overview.jsp
> > > > >
> > > > > 2) I want to change this to go to "overview_2.jsp"
> > > > >
> > > > > 3) so I won't change anything in the managed-bean-method, but create
> a
> > > > > new navigation-rule (in your case, I'd need to change the
> > > > > navigation-rule - where is the maintenance difference, I don't touch
> > > > > my managed-bean?)
> > > > >
> > > > > 4) If I want to go to somewhere else from any other page, I'll need
> to
> > > > > create additional navigation-rules, according to the concept of JSF.
> > > > >
> > > > > Essence is - you don't have to change anything in your managed bean,
> > > > > you  just add configuration rules where necessary, but keep them out
> > > > > where unnecessary.
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 10/30/06, Craig McClanahan < craigmcc@apache.org > wrote:
> > > > > >
> > > > > >
> > > > > > On 10/30/06, Martin Marinschek < martin.marinschek@gmail.com>
> wrote:
> > > > > > > Hi Craig,
> > > > > > >
> > > > > > > you have been argumenting into this direction before, and I'm
> sorry
> > > to
> > > > > > > disagree completely. What JSF does in the standard is good for
> > > > > > > projects where you have this necessity of different roles for
> page
> > > > > > > development and back-end development.
> > > > > >
> > > > > > It's not a matter of different roles.  The design principles I
> > > advocate are
> > > > > > the same whether there is one developer performing multiple roles,
> or
> > > > > > different developers (or developer groups) performing the
> different
> > > roles.
> > > > > >
> > > > > > The architectural issues here are exactly the same in either case.
> > > > > >
> > > > > > > Generally - for small projects, and the majority of web-projects
> are
> > > > > > > still small projects, the person writing the navigation-handling
> > > code,
> > > > > > > the page, and the backing-bean will be the same, so why not give
> > > them
> > > > > > > the ability to have a convention-over-configuration approach?
> You
> > > can
> > > > > > > always override convention-over-configuration by supplying
> > > > > > > configuration!
> > > > > >
> > > > > > Because that user will be crying alligator tears a year from now,
> or a
> > > month
> > > > > > from now, when the person responsible for the overall organization
> of
> > > the
> > > > > > webapp changes the set of view identifiers that represents the UI
> of
> > > an app.
> > > > > >  WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.  That
> is a
> > > > > > cross-linkage between view tier and model tier that I find
> > > unacceptable in
> > > > > > large scale apps.
> > > > > >
> > > > > > You have a seductive argument with respect to small scale apps.
> But I
> > > can
> > > > > > tell you from 30 years of professional software development
> experience
> > > that
> > > > > > managers tend to buy in to this kind of attitude at the prototype
> > > stage,
> > > > > > when ongoing application maintenance is not a consideration.  And
> > > those
> > > > > > types of people tend to be really unhappy when the effects of this
> > > type of
> > > > > > decision cause their maintenance budgets to skyrocket.  The scale
> of
> > > the app
> > > > > > does not actually matter -- the percentage of the overall budget
> that
> > > must
> > > > > > be allocated to reworking previously running code is *always* a
> major
> > > > > > consideration.
> > > > > >
> > > > > > > Furthermore, I seem to resemble that in the discussion about
> > > > > > > annotations you've made the same proposal as Ernst has at the
> > > > > > > beginning of this discussion - writing a custom
> navigation-handler
> > > > > > > which enables one to optionally not configure navigations, and
> not
> > > > > > > handle navigation via annotations.
> > > > > >
> > > > > > I am *adamantly* in the "no annotations for navigaiton" camp ...
> > > navigation
> > > > > > is absolutely *not* something that should be done with
> annotations.
> > > Doing
> > > > > > so would have the same effect as implementing the suggested
> approach
> > > -- it
> > > > > > would be requiring the person developing the server side business
> > > logic to
> > > > > > be intimately aware of view tier considerations like "what view
> should
> > > I
> > > > > > show next?".
> > > > > >
> > > > > > Doing so makes it basically impossible to reuse business logic in
> > > scenarios
> > > > > > like:
> > > > > >
> > > > > > * Migrating a non-AJAX app to be AJAX-enabled
> > > > > >
> > > > > > * Using the same business logic for REST-based or SOAP-based
> > > > > >   web services
> > > > > >
> > > > > > In short, I believe that requiring the developer of an action
> method
> > > to know
> > > > > > anything about what the view tier will do next is a ***very*** bad
> > > idea.
> > > > > >
> > > > > > You might note that the Shale Tiger Extensions have no provision
> for
> > > > > > annotation based navigation.  That is a deliberate design choice,
> not
> > > one
> > > > > > based on limited development time :-)
> > > > > >
> > > > > > > regards,
> > > > > > >
> > > > > > > Martin
> > > > > >
> > > > > >
> > > > > > Craig
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > http://www.irian.at
> > > > >
> > > > > Your JSF powerhouse -
> > > > > JSF Consulting, Development and
> > > > > Courses in English and German
> > > > >
> > > > > Professional Support for Apache MyFaces
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Arash Rajaeeyan
> > >
> > >
> > >
> > > --
> > > http://learnjsf.com
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
>
> --
> Arash Rajaeeyan


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Option for NavigationHandler to support viewIds as outcome

[Arash Rajaeeyan <ar...@gmail.com>]

Hi Martin,
may be this feature is very good for highly professional developer like you,
but consider those developers new in JSF.

what is the different between this and using forward and redirect methods,
from developer point of view? (not considering JSF life cycle problems)

(if a developer uses forward and direct, then s/he is not even forced to
define a view for their page in facesconfig file! and he can use the same
methods he may already know from JSP/ Servlet)

I have seen lots of .net and JSP developers who were trying to use
navigation rules just the way as redirects. and complaining about how hard
is it in JSF to redirect into another page, (complex methods), I think this
is just as Craig says because they haven't understand the deep rationality
behind navigation mechanism yet, and this feature will help them never
understand it!

On 10/30/06, Martin Marinschek <ma...@gmail.com> wrote:
>
> Hi David,
>
> @breaking tool support: yes, that's true, and is something that might
> or might not be of interest to developers.
>
> @application size: For an application with 2000 views, we're
> definitely talking about large-size here. I'm absolutely d'accord that
> for a large size applications with a high number of developers
> assigned to them the normal navigation system should be used.
>
> Having the option of not using the default navigation system for
> small, simple applications is something positive, though.
>
> regards,
>
> Martin
>
> On 10/30/06, David Chandler <da...@learnjsf.com> wrote:
> > Don't forget that returning view IDs in outcomes will break tool support
> > such as the visual page flow designer in Exadel Studio. Even without
> tools,
> > I find it extremely helpful as a developer to be able to look in one
> place
> > to see how the application flows. The proposed capability would make
> that
> > impossible, so I agree with Craig and Arash that returning view IDs in
> > outcomes is unsuitable for apps that will be maintained by multiple
> > developers.
> >
> > Having worked as one of 30+ developers on a large application (2000
> views)
> > written in a scripting language that effectively returned view IDs in
> > outcomes, I can testify to the horrors of code maintenance with this
> > approach. Introducing finite state machine navigation into that code
> base
> > and moving nav rules to config files has made it much easier to work on.
> >
> > David Chandler
> > JSF Consultant / Trainer
> > learnjsf.com
> >
> >
> > On 10/30/06, Arash Rajaeeyan < arash.rajaeeyan@gmail.com> wrote:
> > > It is much easier for a developer (especially if they are beginners in
> > JSF) to return name of the page instead of event occurred in page
> (logical
> > outcome) as output.
> > >
> > >
> > > There are some bad development practices, which when a developer get
> used
> > to them, it is hard to forget, I think this feature is one of them.
> > >
> > > since this bad practice(same reasons as described by Craig), makes
> life
> > easier for them, when they have this feature they will get addicted to
> it,
> > and they won't learn the real idea behind outcomes.
> > >
> > >
> > > I think this is like giving marijuana to JSF developers! Like the
> cartoon
> > in the theserverside.com about AOP considered harmful ;-) Regards
> > > Arash
> > >
> > >
> > >
> > > On 10/30/06, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > Hi Craig,
> > > >
> > > > It's all about convention over configuration, and this concept is in
> > > > turn very good for maintenance. Writing unnecessary configuration
> code
> > > > isn't.
> > > >
> > > > Let's look at an automatic navigation handler in practice:
> > > >
> > > > 1) I have a managed-bean action-method which returns "overview" and
> > > > this means, I'll go to overview.jsp
> > > >
> > > > 2) I want to change this to go to "overview_2.jsp"
> > > >
> > > > 3) so I won't change anything in the managed-bean-method, but create
> a
> > > > new navigation-rule (in your case, I'd need to change the
> > > > navigation-rule - where is the maintenance difference, I don't touch
> > > > my managed-bean?)
> > > >
> > > > 4) If I want to go to somewhere else from any other page, I'll need
> to
> > > > create additional navigation-rules, according to the concept of JSF.
> > > >
> > > > Essence is - you don't have to change anything in your managed bean,
> > > > you  just add configuration rules where necessary, but keep them out
> > > > where unnecessary.
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 10/30/06, Craig McClanahan <craigmcc@apache.org > wrote:
> > > > >
> > > > >
> > > > > On 10/30/06, Martin Marinschek < martin.marinschek@gmail.com>
> wrote:
> > > > > > Hi Craig,
> > > > > >
> > > > > > you have been argumenting into this direction before, and I'm
> sorry
> > to
> > > > > > disagree completely. What JSF does in the standard is good for
> > > > > > projects where you have this necessity of different roles for
> page
> > > > > > development and back-end development.
> > > > >
> > > > > It's not a matter of different roles.  The design principles I
> > advocate are
> > > > > the same whether there is one developer performing multiple roles,
> or
> > > > > different developers (or developer groups) performing the
> different
> > roles.
> > > > >
> > > > > The architectural issues here are exactly the same in either case.
> > > > >
> > > > > > Generally - for small projects, and the majority of web-projects
> are
> > > > > > still small projects, the person writing the navigation-handling
> > code,
> > > > > > the page, and the backing-bean will be the same, so why not give
> > them
> > > > > > the ability to have a convention-over-configuration approach?
> You
> > can
> > > > > > always override convention-over-configuration by supplying
> > > > > > configuration!
> > > > >
> > > > > Because that user will be crying alligator tears a year from now,
> or a
> > month
> > > > > from now, when the person responsible for the overall organization
> of
> > the
> > > > > webapp changes the set of view identifiers that represents the UI
> of
> > an app.
> > > > >  WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.  That
> is a
> > > > > cross-linkage between view tier and model tier that I find
> > unacceptable in
> > > > > large scale apps.
> > > > >
> > > > > You have a seductive argument with respect to small scale
> apps.  But I
> > can
> > > > > tell you from 30 years of professional software development
> experience
> > that
> > > > > managers tend to buy in to this kind of attitude at the prototype
> > stage,
> > > > > when ongoing application maintenance is not a consideration.  And
> > those
> > > > > types of people tend to be really unhappy when the effects of this
> > type of
> > > > > decision cause their maintenance budgets to skyrocket.  The scale
> of
> > the app
> > > > > does not actually matter -- the percentage of the overall budget
> that
> > must
> > > > > be allocated to reworking previously running code is *always* a
> major
> > > > > consideration.
> > > > >
> > > > > > Furthermore, I seem to resemble that in the discussion about
> > > > > > annotations you've made the same proposal as Ernst has at the
> > > > > > beginning of this discussion - writing a custom
> navigation-handler
> > > > > > which enables one to optionally not configure navigations, and
> not
> > > > > > handle navigation via annotations.
> > > > >
> > > > > I am *adamantly* in the "no annotations for navigaiton" camp ...
> > navigation
> > > > > is absolutely *not* something that should be done with
> annotations.
> > Doing
> > > > > so would have the same effect as implementing the suggested
> approach
> > -- it
> > > > > would be requiring the person developing the server side business
> > logic to
> > > > > be intimately aware of view tier considerations like "what view
> should
> > I
> > > > > show next?".
> > > > >
> > > > > Doing so makes it basically impossible to reuse business logic in
> > scenarios
> > > > > like:
> > > > >
> > > > > * Migrating a non-AJAX app to be AJAX-enabled
> > > > >
> > > > > * Using the same business logic for REST-based or SOAP-based
> > > > >   web services
> > > > >
> > > > > In short, I believe that requiring the developer of an action
> method
> > to know
> > > > > anything about what the view tier will do next is a ***very*** bad
> > idea.
> > > > >
> > > > > You might note that the Shale Tiger Extensions have no provision
> for
> > > > > annotation based navigation.  That is a deliberate design choice,
> not
> > one
> > > > > based on limited development time :-)
> > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > >
> > > > >
> > > > > Craig
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > >
> > > > Your JSF powerhouse -
> > > > JSF Consulting, Development and
> > > > Courses in English and German
> > > >
> > > > Professional Support for Apache MyFaces
> > > >
> > >
> > >
> > >
> > > --
> > > Arash Rajaeeyan
> >
> >
> >
> > --
> > http://learnjsf.com
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>



-- 
Arash Rajaeeyan

Re: Option for NavigationHandler to support viewIds as outcome

[Martin Marinschek <ma...@gmail.com>]

Hi David,

@breaking tool support: yes, that's true, and is something that might
or might not be of interest to developers.

@application size: For an application with 2000 views, we're
definitely talking about large-size here. I'm absolutely d'accord that
for a large size applications with a high number of developers
assigned to them the normal navigation system should be used.

Having the option of not using the default navigation system for
small, simple applications is something positive, though.

regards,

Martin

On 10/30/06, David Chandler <da...@learnjsf.com> wrote:
> Don't forget that returning view IDs in outcomes will break tool support
> such as the visual page flow designer in Exadel Studio. Even without tools,
> I find it extremely helpful as a developer to be able to look in one place
> to see how the application flows. The proposed capability would make that
> impossible, so I agree with Craig and Arash that returning view IDs in
> outcomes is unsuitable for apps that will be maintained by multiple
> developers.
>
> Having worked as one of 30+ developers on a large application (2000 views)
> written in a scripting language that effectively returned view IDs in
> outcomes, I can testify to the horrors of code maintenance with this
> approach. Introducing finite state machine navigation into that code base
> and moving nav rules to config files has made it much easier to work on.
>
> David Chandler
> JSF Consultant / Trainer
> learnjsf.com
>
>
> On 10/30/06, Arash Rajaeeyan < arash.rajaeeyan@gmail.com> wrote:
> > It is much easier for a developer (especially if they are beginners in
> JSF) to return name of the page instead of event occurred in page (logical
> outcome) as output.
> >
> >
> > There are some bad development practices, which when a developer get used
> to them, it is hard to forget, I think this feature is one of them.
> >
> > since this bad practice(same reasons as described by Craig), makes life
> easier for them, when they have this feature they will get addicted to it,
> and they won't learn the real idea behind outcomes.
> >
> >
> > I think this is like giving marijuana to JSF developers! Like the cartoon
> in the theserverside.com about AOP considered harmful ;-) Regards
> > Arash
> >
> >
> >
> > On 10/30/06, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > Hi Craig,
> > >
> > > It's all about convention over configuration, and this concept is in
> > > turn very good for maintenance. Writing unnecessary configuration code
> > > isn't.
> > >
> > > Let's look at an automatic navigation handler in practice:
> > >
> > > 1) I have a managed-bean action-method which returns "overview" and
> > > this means, I'll go to overview.jsp
> > >
> > > 2) I want to change this to go to "overview_2.jsp"
> > >
> > > 3) so I won't change anything in the managed-bean-method, but create a
> > > new navigation-rule (in your case, I'd need to change the
> > > navigation-rule - where is the maintenance difference, I don't touch
> > > my managed-bean?)
> > >
> > > 4) If I want to go to somewhere else from any other page, I'll need to
> > > create additional navigation-rules, according to the concept of JSF.
> > >
> > > Essence is - you don't have to change anything in your managed bean,
> > > you  just add configuration rules where necessary, but keep them out
> > > where unnecessary.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 10/30/06, Craig McClanahan <craigmcc@apache.org > wrote:
> > > >
> > > >
> > > > On 10/30/06, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > > Hi Craig,
> > > > >
> > > > > you have been argumenting into this direction before, and I'm sorry
> to
> > > > > disagree completely. What JSF does in the standard is good for
> > > > > projects where you have this necessity of different roles for page
> > > > > development and back-end development.
> > > >
> > > > It's not a matter of different roles.  The design principles I
> advocate are
> > > > the same whether there is one developer performing multiple roles, or
> > > > different developers (or developer groups) performing the different
> roles.
> > > >
> > > > The architectural issues here are exactly the same in either case.
> > > >
> > > > > Generally - for small projects, and the majority of web-projects are
> > > > > still small projects, the person writing the navigation-handling
> code,
> > > > > the page, and the backing-bean will be the same, so why not give
> them
> > > > > the ability to have a convention-over-configuration approach? You
> can
> > > > > always override convention-over-configuration by supplying
> > > > > configuration!
> > > >
> > > > Because that user will be crying alligator tears a year from now, or a
> month
> > > > from now, when the person responsible for the overall organization of
> the
> > > > webapp changes the set of view identifiers that represents the UI of
> an app.
> > > >  WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.  That is a
> > > > cross-linkage between view tier and model tier that I find
> unacceptable in
> > > > large scale apps.
> > > >
> > > > You have a seductive argument with respect to small scale apps.  But I
> can
> > > > tell you from 30 years of professional software development experience
> that
> > > > managers tend to buy in to this kind of attitude at the prototype
> stage,
> > > > when ongoing application maintenance is not a consideration.  And
> those
> > > > types of people tend to be really unhappy when the effects of this
> type of
> > > > decision cause their maintenance budgets to skyrocket.  The scale of
> the app
> > > > does not actually matter -- the percentage of the overall budget that
> must
> > > > be allocated to reworking previously running code is *always* a major
> > > > consideration.
> > > >
> > > > > Furthermore, I seem to resemble that in the discussion about
> > > > > annotations you've made the same proposal as Ernst has at the
> > > > > beginning of this discussion - writing a custom navigation-handler
> > > > > which enables one to optionally not configure navigations, and not
> > > > > handle navigation via annotations.
> > > >
> > > > I am *adamantly* in the "no annotations for navigaiton" camp ...
> navigation
> > > > is absolutely *not* something that should be done with annotations.
> Doing
> > > > so would have the same effect as implementing the suggested approach
> -- it
> > > > would be requiring the person developing the server side business
> logic to
> > > > be intimately aware of view tier considerations like "what view should
> I
> > > > show next?".
> > > >
> > > > Doing so makes it basically impossible to reuse business logic in
> scenarios
> > > > like:
> > > >
> > > > * Migrating a non-AJAX app to be AJAX-enabled
> > > >
> > > > * Using the same business logic for REST-based or SOAP-based
> > > >   web services
> > > >
> > > > In short, I believe that requiring the developer of an action method
> to know
> > > > anything about what the view tier will do next is a ***very*** bad
> idea.
> > > >
> > > > You might note that the Shale Tiger Extensions have no provision for
> > > > annotation based navigation.  That is a deliberate design choice, not
> one
> > > > based on limited development time :-)
> > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > >
> > > >
> > > > Craig
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
> >
> >
> > --
> > Arash Rajaeeyan
>
>
>
> --
> http://learnjsf.com


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Option for NavigationHandler to support viewIds as outcome

[David Chandler <da...@learnjsf.com>]

Don't forget that returning view IDs in outcomes will break tool support
such as the visual page flow designer in Exadel Studio. Even without tools,
I find it extremely helpful as a developer to be able to look in one place
to see how the application flows. The proposed capability would make that
impossible, so I agree with Craig and Arash that returning view IDs in
outcomes is unsuitable for apps that will be maintained by multiple
developers.

Having worked as one of 30+ developers on a large application (2000 views)
written in a scripting language that effectively returned view IDs in
outcomes, I can testify to the horrors of code maintenance with this
approach. Introducing finite state machine navigation into that code base
and moving nav rules to config files has made it much easier to work on.

David Chandler
JSF Consultant / Trainer
learnjsf.com

On 10/30/06, Arash Rajaeeyan <ar...@gmail.com> wrote:
>
> It is much easier for a developer (especially if they are beginners in
> JSF) to return name of the page instead of event occurred in page (logical
> outcome) as output.
>
> There are some bad development practices, which when a developer get used
> to them, it is hard to forget, I think this feature is one of them.
>
> since this bad practice(same reasons as described by Craig), makes life
> easier for them, when they have this feature they will get addicted to it,
> and they won't learn the real idea behind outcomes.
>
> I think this is like giving marijuana to JSF developers! Like the cartoon
> in the theserverside.com about AOP considered harmful ;-)
> Regards
> Arash
>
> On 10/30/06, Martin Marinschek <ma...@gmail.com> wrote:
> >
> > Hi Craig,
> >
> > It's all about convention over configuration, and this concept is in
> > turn very good for maintenance. Writing unnecessary configuration code
> > isn't.
> >
> > Let's look at an automatic navigation handler in practice:
> >
> > 1) I have a managed-bean action-method which returns "overview" and
> > this means, I'll go to overview.jsp
> >
> > 2) I want to change this to go to "overview_2.jsp"
> >
> > 3) so I won't change anything in the managed-bean-method, but create a
> > new navigation-rule (in your case, I'd need to change the
> > navigation-rule - where is the maintenance difference, I don't touch
> > my managed-bean?)
> >
> > 4) If I want to go to somewhere else from any other page, I'll need to
> > create additional navigation-rules, according to the concept of JSF.
> >
> > Essence is - you don't have to change anything in your managed bean,
> > you  just add configuration rules where necessary, but keep them out
> > where unnecessary.
> >
> > regards,
> >
> > Martin
> >
> > On 10/30/06, Craig McClanahan <cr...@apache.org> wrote:
> > >
> > >
> > > On 10/30/06, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > Hi Craig,
> > > >
> > > > you have been argumenting into this direction before, and I'm sorry
> > to
> > > > disagree completely. What JSF does in the standard is good for
> > > > projects where you have this necessity of different roles for page
> > > > development and back-end development.
> > >
> > > It's not a matter of different roles.  The design principles I
> > advocate are
> > > the same whether there is one developer performing multiple roles, or
> > > different developers (or developer groups) performing the different
> > roles.
> > >
> > > The architectural issues here are exactly the same in either case.
> > >
> > > > Generally - for small projects, and the majority of web-projects are
> > > > still small projects, the person writing the navigation-handling
> > code,
> > > > the page, and the backing-bean will be the same, so why not give
> > them
> > > > the ability to have a convention-over-configuration approach? You
> > can
> > > > always override convention-over-configuration by supplying
> > > > configuration!
> > >
> > > Because that user will be crying alligator tears a year from now, or a
> > month
> > > from now, when the person responsible for the overall organization of
> > the
> > > webapp changes the set of view identifiers that represents the UI of
> > an app.
> > >  WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.  That is a
> > > cross-linkage between view tier and model tier that I find
> > unacceptable in
> > > large scale apps.
> > >
> > > You have a seductive argument with respect to small scale apps.  But I
> > can
> > > tell you from 30 years of professional software development experience
> > that
> > > managers tend to buy in to this kind of attitude at the prototype
> > stage,
> > > when ongoing application maintenance is not a consideration.  And
> > those
> > > types of people tend to be really unhappy when the effects of this
> > type of
> > > decision cause their maintenance budgets to skyrocket.  The scale of
> > the app
> > > does not actually matter -- the percentage of the overall budget that
> > must
> > > be allocated to reworking previously running code is *always* a major
> > > consideration.
> > >
> > > > Furthermore, I seem to resemble that in the discussion about
> > > > annotations you've made the same proposal as Ernst has at the
> > > > beginning of this discussion - writing a custom navigation-handler
> > > > which enables one to optionally not configure navigations, and not
> > > > handle navigation via annotations.
> > >
> > > I am *adamantly* in the "no annotations for navigaiton" camp ...
> > navigation
> > > is absolutely *not* something that should be done with
> > annotations.  Doing
> > > so would have the same effect as implementing the suggested approach
> > -- it
> > > would be requiring the person developing the server side business
> > logic to
> > > be intimately aware of view tier considerations like "what view should
> > I
> > > show next?".
> > >
> > > Doing so makes it basically impossible to reuse business logic in
> > scenarios
> > > like:
> > >
> > > * Migrating a non-AJAX app to be AJAX-enabled
> > >
> > > * Using the same business logic for REST-based or SOAP-based
> > >   web services
> > >
> > > In short, I believe that requiring the developer of an action method
> > to know
> > > anything about what the view tier will do next is a ***very*** bad
> > idea.
> > >
> > > You might note that the Shale Tiger Extensions have no provision for
> > > annotation based navigation.  That is a deliberate design choice, not
> > one
> > > based on limited development time :-)
> > >
> > > > regards,
> > > >
> > > > Martin
> > >
> > >
> > > Craig
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
>
> --
> Arash Rajaeeyan




-- 
http://learnjsf.com

Re: Option for NavigationHandler to support viewIds as outcome

[Arash Rajaeeyan <ar...@gmail.com>]

It is much easier for a developer (especially if they are beginners in JSF)
to return name of the page instead of event occurred in page (logical
outcome) as output.

There are some bad development practices, which when a developer get used to
them, it is hard to forget, I think this feature is one of them.

since this bad practice(same reasons as described by Craig), makes life
easier for them, when they have this feature they will get addicted to it,
and they won't learn the real idea behind outcomes.

I think this is like giving marijuana to JSF developers! Like the cartoon in
the theserverside.com about AOP considered harmful ;-)
Regards
Arash

On 10/30/06, Martin Marinschek <ma...@gmail.com> wrote:
>
> Hi Craig,
>
> It's all about convention over configuration, and this concept is in
> turn very good for maintenance. Writing unnecessary configuration code
> isn't.
>
> Let's look at an automatic navigation handler in practice:
>
> 1) I have a managed-bean action-method which returns "overview" and
> this means, I'll go to overview.jsp
>
> 2) I want to change this to go to "overview_2.jsp"
>
> 3) so I won't change anything in the managed-bean-method, but create a
> new navigation-rule (in your case, I'd need to change the
> navigation-rule - where is the maintenance difference, I don't touch
> my managed-bean?)
>
> 4) If I want to go to somewhere else from any other page, I'll need to
> create additional navigation-rules, according to the concept of JSF.
>
> Essence is - you don't have to change anything in your managed bean,
> you  just add configuration rules where necessary, but keep them out
> where unnecessary.
>
> regards,
>
> Martin
>
> On 10/30/06, Craig McClanahan <cr...@apache.org> wrote:
> >
> >
> > On 10/30/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > Hi Craig,
> > >
> > > you have been argumenting into this direction before, and I'm sorry to
> > > disagree completely. What JSF does in the standard is good for
> > > projects where you have this necessity of different roles for page
> > > development and back-end development.
> >
> > It's not a matter of different roles.  The design principles I advocate
> are
> > the same whether there is one developer performing multiple roles, or
> > different developers (or developer groups) performing the different
> roles.
> >
> > The architectural issues here are exactly the same in either case.
> >
> > > Generally - for small projects, and the majority of web-projects are
> > > still small projects, the person writing the navigation-handling code,
> > > the page, and the backing-bean will be the same, so why not give them
> > > the ability to have a convention-over-configuration approach? You can
> > > always override convention-over-configuration by supplying
> > > configuration!
> >
> > Because that user will be crying alligator tears a year from now, or a
> month
> > from now, when the person responsible for the overall organization of
> the
> > webapp changes the set of view identifiers that represents the UI of an
> app.
> >  WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.  That is a
> > cross-linkage between view tier and model tier that I find unacceptable
> in
> > large scale apps.
> >
> > You have a seductive argument with respect to small scale apps.  But I
> can
> > tell you from 30 years of professional software development experience
> that
> > managers tend to buy in to this kind of attitude at the prototype stage,
> > when ongoing application maintenance is not a consideration.  And those
> > types of people tend to be really unhappy when the effects of this type
> of
> > decision cause their maintenance budgets to skyrocket.  The scale of the
> app
> > does not actually matter -- the percentage of the overall budget that
> must
> > be allocated to reworking previously running code is *always* a major
> > consideration.
> >
> > > Furthermore, I seem to resemble that in the discussion about
> > > annotations you've made the same proposal as Ernst has at the
> > > beginning of this discussion - writing a custom navigation-handler
> > > which enables one to optionally not configure navigations, and not
> > > handle navigation via annotations.
> >
> > I am *adamantly* in the "no annotations for navigaiton" camp ...
> navigation
> > is absolutely *not* something that should be done with
> annotations.  Doing
> > so would have the same effect as implementing the suggested approach --
> it
> > would be requiring the person developing the server side business logic
> to
> > be intimately aware of view tier considerations like "what view should I
> > show next?".
> >
> > Doing so makes it basically impossible to reuse business logic in
> scenarios
> > like:
> >
> > * Migrating a non-AJAX app to be AJAX-enabled
> >
> > * Using the same business logic for REST-based or SOAP-based
> >   web services
> >
> > In short, I believe that requiring the developer of an action method to
> know
> > anything about what the view tier will do next is a ***very*** bad idea.
> >
> > You might note that the Shale Tiger Extensions have no provision for
> > annotation based navigation.  That is a deliberate design choice, not
> one
> > based on limited development time :-)
> >
> > > regards,
> > >
> > > Martin
> >
> >
> > Craig
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>



-- 
Arash Rajaeeyan

Re: Option for NavigationHandler to support viewIds as outcome

[Martin Marinschek <ma...@gmail.com>]

Hi Craig,

It's all about convention over configuration, and this concept is in
turn very good for maintenance. Writing unnecessary configuration code
isn't.

Let's look at an automatic navigation handler in practice:

1) I have a managed-bean action-method which returns "overview" and
this means, I'll go to overview.jsp

2) I want to change this to go to "overview_2.jsp"

3) so I won't change anything in the managed-bean-method, but create a
new navigation-rule (in your case, I'd need to change the
navigation-rule - where is the maintenance difference, I don't touch
my managed-bean?)

4) If I want to go to somewhere else from any other page, I'll need to
create additional navigation-rules, according to the concept of JSF.

Essence is - you don't have to change anything in your managed bean,
you  just add configuration rules where necessary, but keep them out
where unnecessary.

regards,

Martin

On 10/30/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
> On 10/30/06, Martin Marinschek <ma...@gmail.com> wrote:
> > Hi Craig,
> >
> > you have been argumenting into this direction before, and I'm sorry to
> > disagree completely. What JSF does in the standard is good for
> > projects where you have this necessity of different roles for page
> > development and back-end development.
>
> It's not a matter of different roles.  The design principles I advocate are
> the same whether there is one developer performing multiple roles, or
> different developers (or developer groups) performing the different roles.
>
> The architectural issues here are exactly the same in either case.
>
> > Generally - for small projects, and the majority of web-projects are
> > still small projects, the person writing the navigation-handling code,
> > the page, and the backing-bean will be the same, so why not give them
> > the ability to have a convention-over-configuration approach? You can
> > always override convention-over-configuration by supplying
> > configuration!
>
> Because that user will be crying alligator tears a year from now, or a month
> from now, when the person responsible for the overall organization of the
> webapp changes the set of view identifiers that represents the UI of an app.
>  WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.  That is a
> cross-linkage between view tier and model tier that I find unacceptable in
> large scale apps.
>
> You have a seductive argument with respect to small scale apps.  But I can
> tell you from 30 years of professional software development experience that
> managers tend to buy in to this kind of attitude at the prototype stage,
> when ongoing application maintenance is not a consideration.  And those
> types of people tend to be really unhappy when the effects of this type of
> decision cause their maintenance budgets to skyrocket.  The scale of the app
> does not actually matter -- the percentage of the overall budget that must
> be allocated to reworking previously running code is *always* a major
> consideration.
>
> > Furthermore, I seem to resemble that in the discussion about
> > annotations you've made the same proposal as Ernst has at the
> > beginning of this discussion - writing a custom navigation-handler
> > which enables one to optionally not configure navigations, and not
> > handle navigation via annotations.
>
> I am *adamantly* in the "no annotations for navigaiton" camp ... navigation
> is absolutely *not* something that should be done with annotations.  Doing
> so would have the same effect as implementing the suggested approach -- it
> would be requiring the person developing the server side business logic to
> be intimately aware of view tier considerations like "what view should I
> show next?".
>
> Doing so makes it basically impossible to reuse business logic in scenarios
> like:
>
> * Migrating a non-AJAX app to be AJAX-enabled
>
> * Using the same business logic for REST-based or SOAP-based
>   web services
>
> In short, I believe that requiring the developer of an action method to know
> anything about what the view tier will do next is a ***very*** bad idea.
>
> You might note that the Shale Tiger Extensions have no provision for
> annotation based navigation.  That is a deliberate design choice, not one
> based on limited development time :-)
>
> > regards,
> >
> > Martin
>
>
> Craig
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Option for NavigationHandler to support viewIds as outcome

[Craig McClanahan <cr...@apache.org>]

On 10/30/06, Martin Marinschek <ma...@gmail.com> wrote:
>
> Hi Craig,
>
> you have been argumenting into this direction before, and I'm sorry to
> disagree completely. What JSF does in the standard is good for
> projects where you have this necessity of different roles for page
> development and back-end development.


It's not a matter of different roles.  The design principles I advocate are
the same whether there is one developer performing multiple roles, or
different developers (or developer groups) performing the different roles.

The architectural issues here are exactly the same in either case.


Generally - for small projects, and the majority of web-projects are
> still small projects, the person writing the navigation-handling code,
> the page, and the backing-bean will be the same, so why not give them
> the ability to have a convention-over-configuration approach? You can
> always override convention-over-configuration by supplying
> configuration!


Because that user will be crying alligator tears a year from now, or a month
from now, when the person responsible for the overall organization of the
webapp changes the set of view identifiers that represents the UI of an
app.  WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.  That is a
cross-linkage between view tier and model tier that I find unacceptable in
large scale apps.

You have a seductive argument with respect to small scale apps.  But I can
tell you from 30 years of professional software development experience that
managers tend to buy in to this kind of attitude at the prototype stage,
when ongoing application maintenance is not a consideration.  And those
types of people tend to be really unhappy when the effects of this type of
decision cause their maintenance budgets to skyrocket.  The scale of the app
does not actually matter -- the percentage of the overall budget that must
be allocated to reworking previously running code is *always* a major
consideration.

Furthermore, I seem to resemble that in the discussion about
> annotations you've made the same proposal as Ernst has at the
> beginning of this discussion - writing a custom navigation-handler
> which enables one to optionally not configure navigations, and not
> handle navigation via annotations.


I am *adamantly* in the "no annotations for navigaiton" camp ... navigation
is absolutely *not* something that should be done with annotations.  Doing
so would have the same effect as implementing the suggested approach -- it
would be requiring the person developing the server side business logic to
be intimately aware of view tier considerations like "what view should I
show next?".

Doing so makes it basically impossible to reuse business logic in scenarios
like:

* Migrating a non-AJAX app to be AJAX-enabled

* Using the same business logic for REST-based or SOAP-based
  web services

In short, I believe that requiring the developer of an action method to know
anything about what the view tier will do next is a ***very*** bad idea.

You might note that the Shale Tiger Extensions have no provision for
annotation based navigation.  That is a deliberate design choice, not one
based on limited development time :-)

regards,
>
> Martin



Craig

Re: Option for NavigationHandler to support viewIds as outcome

[Martin Marinschek <ma...@gmail.com>]

Hi Craig,

you have been argumenting into this direction before, and I'm sorry to
disagree completely. What JSF does in the standard is good for
projects where you have this necessity of different roles for page
development and back-end development.

Generally - for small projects, and the majority of web-projects are
still small projects, the person writing the navigation-handling code,
the page, and the backing-bean will be the same, so why not give them
the ability to have a convention-over-configuration approach? You can
always override convention-over-configuration by supplying
configuration!

Furthermore, I seem to resemble that in the discussion about
annotations you've made the same proposal as Ernst has at the
beginning of this discussion - writing a custom navigation-handler
which enables one to optionally not configure navigations, and not
handle navigation via annotations.

regards,

Martin

On 10/30/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
> On 10/29/06, Ernst Fastl <er...@gmail.com> wrote:
> > Hi!
> >
> > At the moment when no navigation case for an outcome is found
> > the navigationHandler decides to stay at the same view. I think
> > an option for web.xml would be useful to tell the navigationHandler
> > if no navigation case for an outcome is found, but the outcome
> > matches a viewId to navigate to this view id.
> >
> > This idea was mainly driven by a lot of jsf-projects where I saw for each
> > view id:
> >
> > <navigation-rule>
> >         <from-view-id>*</from-view-id>
> >         <navigation-case>
> >             <from-outcome>viewId</from-outcome>
> >             <to-view-id>/viewId.xhtml</to-view-id>
> >             <redirect/>
> >         </navigation-case>
> > ...
> >
> >
> > which seems kind of unnecessary to me
> >
> > what do you think about that?
>
> I think that the developers of projects like that did not actually
> understand the reasoning behind the standard JSF approach to navigation.
>
> The basic theory is that an action method should return a *logical outcome*
> -- a string that says "this is what happened", not a string that says "go to
> this page next".  That decision should be left to the architect who is
> gluing things all together.  In particular, you should *want* to have the
> ability to remodel your view identifiers namespace, *without* having to go
> modify every single action method that returns a view id instead of a
> logical outcome.
>
> Consider the following use case to understand what's going on here.  Lots of
> web sites have search text fields (like Google's search text field) that can
> be used to select the relevant database information.  Let's assume, for the
> purposes of discussion, that such a text field exists to select a customer
> from your database of current customers.  Next, let's look at this issue
> from the viewpoint of the developer who is writing the action method that
> responds to a user entering a value into the search field.  If you are
> following good application design principles, this person will *not* know
> (or care) about what page should be displayed next.  Instead, he or she will
> be focused on the fact that there are three logical outcomes that can result
> from a database search based on criteria specified in the search field:
>
> * No matching results were found.
>
> * Exactly one matching result was found.
>
> * More than one matching result was found.
>
> In a very simple minded application (or a RAD-developed prototype), you
> might be satisfied with only doing one thing in all three cases.  In a
> user-friendly app, on the other hand, you might want to react like this:
>
> * No results -- show the search criteria page again with
>   a message saying "I'm sorry, no matches were found --
>   please refine your search criteria".
>
> * Exactly one result -- go directly to the next step in the
>   user conversation, having selected a particular master record.
>
> * More than one result -- go to a page that lists the available
>   matches and lets the user select the desired one.
>
> The key issue here ... THE DEVELOPER WRITING THE ACTION METHOD FOR THE
> SEARCH SHOULD NOT NEED TO KNOW WHAT HAPPENS NEXT.  The important
> responsibility is to report "this is what happened" (one of the three
> logical outcomes).  It's up to the rest of the application to react to this
> event.  And, over the lifetime of the application, this reaction might
> change -- but you should *not* have to go back and do the original code over
> again.
>
> Given this background, I believe that the proposed feature here is *not* a
> good idea.  It is counter to the basic philosophy behind the navigation
> handler architecture that the JSF spec defines.
>
> > regards
> >
> > Ernst
> >
>
>
> Craig McClanahan
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Option for NavigationHandler to support viewIds as outcome

[Craig McClanahan <cr...@apache.org>]

On 10/29/06, Ernst Fastl <er...@gmail.com> wrote:
>
> Hi!
>
> At the moment when no navigation case for an outcome is found
> the navigationHandler decides to stay at the same view. I think
> an option for web.xml would be useful to tell the navigationHandler
> if no navigation case for an outcome is found, but the outcome
> matches a viewId to navigate to this view id.
>
> This idea was mainly driven by a lot of jsf-projects where I saw for each
> view id:
>
> <navigation-rule>
>         <from-view-id>*</from-view-id>
>         <navigation-case>
>             <from-outcome>viewId</from-outcome>
>             <to-view-id>/viewId.xhtml</to-view-id>
>             <redirect/>
>         </navigation-case>
> ...
>
>
> which seems kind of unnecessary to me
>
> what do you think about that?


I think that the developers of projects like that did not actually
understand the reasoning behind the standard JSF approach to navigation.

The basic theory is that an action method should return a *logical outcome*
-- a string that says "this is what happened", not a string that says "go to
this page next".  That decision should be left to the architect who is
gluing things all together.  In particular, you should *want* to have the
ability to remodel your view identifiers namespace, *without* having to go
modify every single action method that returns a view id instead of a
logical outcome.

Consider the following use case to understand what's going on here.  Lots of
web sites have search text fields (like Google's search text field) that can
be used to select the relevant database information.  Let's assume, for the
purposes of discussion, that such a text field exists to select a customer
from your database of current customers.  Next, let's look at this issue
from the viewpoint of the developer who is writing the action method that
responds to a user entering a value into the search field.  If you are
following good application design principles, this person will *not* know
(or care) about what page should be displayed next.  Instead, he or she will
be focused on the fact that there are three logical outcomes that can result
from a database search based on criteria specified in the search field:

* No matching results were found.

* Exactly one matching result was found.

* More than one matching result was found.

In a very simple minded application (or a RAD-developed prototype), you
might be satisfied with only doing one thing in all three cases.  In a
user-friendly app, on the other hand, you might want to react like this:

* No results -- show the search criteria page again with
  a message saying "I'm sorry, no matches were found --
  please refine your search criteria".

* Exactly one result -- go directly to the next step in the
  user conversation, having selected a particular master record.

* More than one result -- go to a page that lists the available
  matches and lets the user select the desired one.

The key issue here ... THE DEVELOPER WRITING THE ACTION METHOD FOR THE
SEARCH SHOULD NOT NEED TO KNOW WHAT HAPPENS NEXT.  The important
responsibility is to report "this is what happened" (one of the three
logical outcomes).  It's up to the rest of the application to react to this
event.  And, over the lifetime of the application, this reaction might
change -- but you should *not* have to go back and do the original code over
again.

Given this background, I believe that the proposed feature here is *not* a
good idea.  It is counter to the basic philosophy behind the navigation
handler architecture that the JSF spec defines.

regards
>
> Ernst
>


Craig McClanahan

Re: Option for NavigationHandler to support viewIds as outcome

[Martin Marinschek <ma...@gmail.com>]

I definitely think Ernst's idea is a good one - and I do think that a
configuration-parameter for adding this would be optimal.

The dummy-form stuff was not compatible with the RI, overwriting a
navigation-handler in tomahawk, behaving differently if a
configuration parameter is set; would of course be!

regards,

Martin

On 10/30/06, Matthias Wessendorf <ma...@apache.org> wrote:
> look at the nh_impl.
>
> you see it :)
>
> On 10/30/06, Ernst Fastl <er...@gmail.com> wrote:
> > Hmm, sounds interesting, what exactly would you have in mind,
> > something like a Callback for additional security checks which receives
> > the viewId and then can check wheather or not access is allowed and
> > return a boolean or so?
> >
> > On 10/30/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl
> > >
> > > for accessing navigation cases. It is important in security cases to
> > > *check* navigation cases ...
> > >
> > > so your impl could benefit from that !
> > >
> > > On 10/29/06, Ernst Fastl <er...@gmail.com> wrote:
> > > > You're right, an alternate NavigationHandler shipped with MyFaces
> > > > is probably the better choice let's go with that approach.
> > > >
> > > > thanks for your ideas
> > > >
> > > > On 10/29/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > > > > 2) since in JSF 1.1 navigation outcomes are string it is completely possible
> > > > > > > for a programmer to have a syntax error in out comes
> > > > > >
> > > > > > Sorry don't get your point here, if an action returns a misspelled outcome
> > > > > > or a misspelled viewId you would not want to navigate in both cases right?
> > > > >
> > > > > I think he means the 404 error, ...
> > > > >
> > > > >
> > > > > However, I kinda like stuff like that, but not configurable!
> > > > > We had had enough fun with bogus features like dummyForm.
> > > > >
> > > > > We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if
> > > > > sb. really really
> > > > > want that, use that particular NH.
> > > > >
> > > > > just my $0.02
> > > > >
> > > > > -M
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > > http://tinyurl.com/fmywh
> > > > >
> > > > > further stuff:
> > > > > blog: http://jroller.com/page/mwessendorf
> > > > > mail: mwessendorf-at-gmail-dot-com
> > > > >
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > > http://tinyurl.com/fmywh
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Option for NavigationHandler to support viewIds as outcome

[Matthias Wessendorf <ma...@apache.org>]

look at the nh_impl.

you see it :)

On 10/30/06, Ernst Fastl <er...@gmail.com> wrote:
> Hmm, sounds interesting, what exactly would you have in mind,
> something like a Callback for additional security checks which receives
> the viewId and then can check wheather or not access is allowed and
> return a boolean or so?
>
> On 10/30/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl
> >
> > for accessing navigation cases. It is important in security cases to
> > *check* navigation cases ...
> >
> > so your impl could benefit from that !
> >
> > On 10/29/06, Ernst Fastl <er...@gmail.com> wrote:
> > > You're right, an alternate NavigationHandler shipped with MyFaces
> > > is probably the better choice let's go with that approach.
> > >
> > > thanks for your ideas
> > >
> > > On 10/29/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > > > 2) since in JSF 1.1 navigation outcomes are string it is completely possible
> > > > > > for a programmer to have a syntax error in out comes
> > > > >
> > > > > Sorry don't get your point here, if an action returns a misspelled outcome
> > > > > or a misspelled viewId you would not want to navigate in both cases right?
> > > >
> > > > I think he means the 404 error, ...
> > > >
> > > >
> > > > However, I kinda like stuff like that, but not configurable!
> > > > We had had enough fun with bogus features like dummyForm.
> > > >
> > > > We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if
> > > > sb. really really
> > > > want that, use that particular NH.
> > > >
> > > > just my $0.02
> > > >
> > > > -M
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > > http://tinyurl.com/fmywh
> > > >
> > > > further stuff:
> > > > blog: http://jroller.com/page/mwessendorf
> > > > mail: mwessendorf-at-gmail-dot-com
> > > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> > http://tinyurl.com/fmywh
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Option for NavigationHandler to support viewIds as outcome

[Ernst Fastl <er...@gmail.com>]

Hmm, sounds interesting, what exactly would you have in mind,
something like a Callback for additional security checks which receives
the viewId and then can check wheather or not access is allowed and
return a boolean or so?

On 10/30/06, Matthias Wessendorf <ma...@apache.org> wrote:
> Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl
>
> for accessing navigation cases. It is important in security cases to
> *check* navigation cases ...
>
> so your impl could benefit from that !
>
> On 10/29/06, Ernst Fastl <er...@gmail.com> wrote:
> > You're right, an alternate NavigationHandler shipped with MyFaces
> > is probably the better choice let's go with that approach.
> >
> > thanks for your ideas
> >
> > On 10/29/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > > 2) since in JSF 1.1 navigation outcomes are string it is completely possible
> > > > > for a programmer to have a syntax error in out comes
> > > >
> > > > Sorry don't get your point here, if an action returns a misspelled outcome
> > > > or a misspelled viewId you would not want to navigate in both cases right?
> > >
> > > I think he means the 404 error, ...
> > >
> > >
> > > However, I kinda like stuff like that, but not configurable!
> > > We had had enough fun with bogus features like dummyForm.
> > >
> > > We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if
> > > sb. really really
> > > want that, use that particular NH.
> > >
> > > just my $0.02
> > >
> > > -M
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > > http://tinyurl.com/fmywh
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>

Re: Option for NavigationHandler to support viewIds as outcome

[Matthias Wessendorf <ma...@apache.org>]

Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl

for accessing navigation cases. It is important in security cases to
*check* navigation cases ...

so your impl could benefit from that !

On 10/29/06, Ernst Fastl <er...@gmail.com> wrote:
> You're right, an alternate NavigationHandler shipped with MyFaces
> is probably the better choice let's go with that approach.
>
> thanks for your ideas
>
> On 10/29/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > 2) since in JSF 1.1 navigation outcomes are string it is completely possible
> > > > for a programmer to have a syntax error in out comes
> > >
> > > Sorry don't get your point here, if an action returns a misspelled outcome
> > > or a misspelled viewId you would not want to navigate in both cases right?
> >
> > I think he means the 404 error, ...
> >
> >
> > However, I kinda like stuff like that, but not configurable!
> > We had had enough fun with bogus features like dummyForm.
> >
> > We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if
> > sb. really really
> > want that, use that particular NH.
> >
> > just my $0.02
> >
> > -M
> >
> >
> > --
> > Matthias Wessendorf
> > http://tinyurl.com/fmywh
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Option for NavigationHandler to support viewIds as outcome

[Ernst Fastl <er...@gmail.com>]

You're right, an alternate NavigationHandler shipped with MyFaces
is probably the better choice let's go with that approach.

thanks for your ideas

On 10/29/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > 2) since in JSF 1.1 navigation outcomes are string it is completely possible
> > > for a programmer to have a syntax error in out comes
> >
> > Sorry don't get your point here, if an action returns a misspelled outcome
> > or a misspelled viewId you would not want to navigate in both cases right?
>
> I think he means the 404 error, ...
>
>
> However, I kinda like stuff like that, but not configurable!
> We had had enough fun with bogus features like dummyForm.
>
> We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if
> sb. really really
> want that, use that particular NH.
>
> just my $0.02
>
> -M
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>

Re: Option for NavigationHandler to support viewIds as outcome

[Matthias Wessendorf <ma...@apache.org>]

> > 2) since in JSF 1.1 navigation outcomes are string it is completely possible
> > for a programmer to have a syntax error in out comes
>
> Sorry don't get your point here, if an action returns a misspelled outcome
> or a misspelled viewId you would not want to navigate in both cases right?

I think he means the 404 error, ...


However, I kinda like stuff like that, but not configurable!
We had had enough fun with bogus features like dummyForm.

We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if
sb. really really
want that, use that particular NH.

just my $0.02

-M


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Option for NavigationHandler to support viewIds as outcome

[Ernst Fastl <er...@gmail.com>]

> 1) it is against the spec behaviour

Of course you are absolutely right with this
therefore I'd make it an optional feature, being able to turn it on with a
configuration parameters

> 2) since in JSF 1.1 navigation outcomes are string it is completely possible
> for a programmer to have a syntax error in out comes

Sorry don't get your point here, if an action returns a misspelled outcome
or a misspelled viewId you would not want to navigate in both cases right?

> 3) this make confusion between page names and outcomes (navigation events)

Confusion is exactly the point, what I get told as the main reason not
to choose
JSF by many users considering it is:
"It is to complex for me I have to write all those xml-files to get
just Hello world running"
That would be a way for them with one configuration file less.

> 4) I think outcomes and names of JSF pages should stay separate.
> JSF navigation is like an finite state machine (FSM) or finite state
> automaton, states are pages and outcomes are input to the automaton, this
> keeps modeling UI very simple.
> and also it makes it possible for formal verification of JSF application,
> with available tools.

Good point. But again, no one would be forced to use the feature, I'd
say it's for starters and lazy programmers, the others can leave it
turned off.

All together, I see your points, but I don't understand
what harm could be caused by an optional feature?



> On 10/30/06, Ernst Fastl <er...@gmail.com> wrote:
> > Hi!
> >
> > At the moment when no navigation case for an outcome is found
> > the navigationHandler decides to stay at the same view. I think
> > an option for web.xml would be useful to tell the navigationHandler
> > if no navigation case for an outcome is found, but the outcome
> > matches a viewId to navigate to this view id.
> >
> > This idea was mainly driven by a lot of jsf-projects where I saw for each
> > view id:
> >
> > <navigation-rule>
> >         <from-view-id>*</from-view-id>
> >         <navigation-case>
> >             <from-outcome>viewId</from-outcome>
> >             <to-view-id>/viewId.xhtml</to-view-id>
> >             <redirect/>
> >         </navigation-case>
> > ...
> >
> >
> > which seems kind of unnecessary to me
> >
> > what do you think about that?
> >
> > regards
> >
> > Ernst
> >
>
>
>

Re: Option for NavigationHandler to support viewIds as outcome

[Arash Rajaeeyan <ar...@gmail.com>]

I think this is a bad idea for following reasons:

1) it is against the spec behaviour
2) since in JSF 1.1 navigation outcomes are string it is completely possible
for a programmer to have a syntax error in out comes
3) this make confusion between page names and outcomes (navigation events)

4) I think outcomes and names of JSF pages should stay separate.
JSF navigation is like an finite state machine (FSM) or finite state
automaton, states are pages and outcomes are input to the automaton, this
keeps modeling UI very simple.
and also it makes it possible for formal verification of JSF application,
with available tools.

Regards
Arash Rajaeeyan


On 10/30/06, Ernst Fastl <er...@gmail.com> wrote:
>
> Hi!
>
> At the moment when no navigation case for an outcome is found
> the navigationHandler decides to stay at the same view. I think
> an option for web.xml would be useful to tell the navigationHandler
> if no navigation case for an outcome is found, but the outcome
> matches a viewId to navigate to this view id.
>
> This idea was mainly driven by a lot of jsf-projects where I saw for each
> view id:
>
> <navigation-rule>
>         <from-view-id>*</from-view-id>
>         <navigation-case>
>             <from-outcome>viewId</from-outcome>
>             <to-view-id>/viewId.xhtml</to-view-id>
>             <redirect/>
>         </navigation-case>
> ...
>
>
> which seems kind of unnecessary to me
>
> what do you think about that?
>
> regards
>
> Ernst
>