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
