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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED] > 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 < [EMAIL PROTECTED] > wrote:
> > > > > >
> > > > > >
> > > > > > On 10/30/06, Martin Marinschek < [EMAIL PROTECTED]>
> 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
