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