• Post Reply Bookmark Topic Watch Topic
  • New Topic

<navigation-rule>

 
Davie Lin
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I inherited a JSF web app from a previous employee of my new Job. I notice that he use a navigation helper class to re dispatch to xhtml files.
I did not see <navigation-rule> entries at all in face-config.xml

Can anyone tell me if this is a good way to implement View layer in JSF or not. can I use <navigation-rule> tag with .xhtml?
any related info is appreciated.
 
Tim Holloway
Bartender
Posts: 18412
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In JSF 1, you needed navigation rules to connect views together. In JSF2, you can specify navigation directly from the Action processors. I don't recommend doing that in most cases, but a lot of people will shout me down on that one.

I have a number of projects that use navigation rules with xhtml. Then again, they mostly run under JSF 1.2 and earlier, so I didn't have the option to do otherwise even if I wanted to.
 
Davie Lin
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Tim for your reply.

From your last response, I take it that the app I inherited implements JSF 2 since the navigation is from the Action processors.
Can you share some of the reasons why you don't recommend this approach?

I am new at JSF and was a Struts developer for a couple of years. If you don't mind answering this.
I notice the app I inherited use the <managed-bean>, besides the normal JavaBean properties and acessor methods, included all business-logic (accessing Spring/Hibernate layer to populate domain model and subsequent processing of domain model). All these bussines-logic methods in the <managed-bean> share one thing in common, it takes ValueChangeEvent object as argument. The ValueChangeEvent object came from the xhtml faclet views tags such as <h:inputText>

Is this a normal and good practice of using <managed-bean> in JSF?

Thanks for your input
 
Tim Holloway
Bartender
Posts: 18412
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ironically, it was Struts that gave me this aversion. I saw some real horrors done using Struts' equivalent of this functionality.

JSF was originally designed with the idea of employing re-usable components (as was EJB). To be really re-usable, a component shouldn't be yanking in other components gratuitously. Otherwise you end up with a great big chunk of non-portable "stuff". To connect (wire) components together without actually coding them that way is what the Inversion of Control (IoC) approach is all about. The wiring is external to the components.

On the other hand, this has been known to devolve into massive external config files, which can be ugly in their own right, and mean that you have to have Yet Another file in your editing set. Because the bean doesn't control where it goes likewise you can't tell where the bean goes by looking at the bean. So at the moment, the Zero Configuration movement is in full cry.

Fortunately, we haven't entirely degenerated into wild pendulum sweeps. There's now a middle ground (a rare thing, alas, in these extremist times). You can configure stuff using annotations, but override the annotations selectively using config files. Which can be smaller and simpler, since they only need to handle the exception cases.

A case where I think the "return a URL" (JSF2) approach is a Good Thing is a sub-function that can be called from multiple places that you want to go back when you're done/cancelled. For that, stashing the return URL and serving it back up from the action processor is wonderful.

Conversely, I think that hard-coding something like an error page URL is a Bad Thing. How I report errors and in what detail has been known to vary, and it's a lot more flexible for me to be able to adjust between different error processes as needed instead of having to go back in and make source code changes.

Thus, the ideal would be a bit of a blend, and, of course that means a certain amount of time spent agonizing on what should/shouldn't use which approach, which will cause the Code Mill managers to demand that everything be Done One Way so that they don't need intelligent programmers, just cheap ones hacking out reams of copy-and-paste code and ... ooops, I'm hyperventilating again.

Sorry. I date back to a time when software was expected to be reliable and of decent quality. A mostly mythical time, I'll admit, but at least we hadn't yet given up all pretense.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!