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
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
As an outcome of this discussion, I'm +1 for 1.
regards,
Martin
On 10/31/06, Mario Ivankovits [EMAIL PROTECTED] 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
On 10/31/06, Mario Ivankovits [EMAIL PROTECTED] 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.)
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
On 10/31/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi! 1.) Seperate NavigationHandlerImplIMHO, this is a must! I think we should *not* implement stuff whichsilently changes/enhances the behaviour - especially in myfaces-impl!!The TCK might forbid this change anyway ...
2.) Configurable
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
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 [EMAIL PROTECTED] wrote:
Ernst, you
look at the nh_impl.
you see it :)
On 10/30/06, Ernst Fastl [EMAIL PROTECTED] 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
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
If you specify the navigation in the faces-config.xml, then you are
already using
a configuration parameter... I this case you would not have to define
another
web-context parameter...
The idea sounds like the DefaultServlet from Tomcat... easy to become
addited to ;)
regards
Alexander
On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote:
Hi!At the moment when no navigation case for an outcome is foundthe navigationHandler decides to stay at the same view. I thinkan option for web.xml would be useful to tell the navigationHandlerif no navigation case for an outcome is found, but the
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
On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Craig,you have been argumenting into this direction before, and I'm sorry todisagree completely. What JSF does in the standard is good forprojects where you have this necessity of different roles for page
development and back-end
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
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
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 [EMAIL PROTECTED]
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
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
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
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
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
On 10/30/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
In reality there is a dependency between two pages, there is a silentcontract how to prepare the managed beans so that the destination pageknows what to display (and I think the f:param stuff is useless here).
So more often than not you'll use
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
I think this is a bad idea for following reasons:1) it is against the spec behaviour2) 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
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
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
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 [EMAIL PROTECTED] wrote:
2) since in JSF 1.1 navigation outcomes are string it is completely possible
for a
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 [EMAIL PROTECTED] wrote:
You're right, an alternate
29 matches
Mail list logo
