On 1/17/06, Werner Punz <[EMAIL PROTECTED]> wrote:
Not currently -- and I doubt I would be in favor of it anyway :-).
Annotations are absolutely fantastic for use cases where there is one and only one decision to make, and it would never be changed anyway because too much other stuff would break. Annotated managed beans are a perfect example of that ... the managed bean name gets baked into every value binding _expression_ that references that bean, and the choice of scope can dramatically affect how and wehre you encode functionality. So why risk having the configuration settings get out of sync because they are in a config file instead of the code?
Navigation is a different situation, however. I believe that the developer creating the backing beans, and therefore implementing the action methods, should be focused on communicating *outcomes* through the return values of the methods. They should describe "what happened" not "where to go next". The navigational aspect of this is up to the person who is architecting the overall navigation of the application, gluing it all together. Even if it is the same person doing both roles, you will improve the quality of your code by separating those concerns. In particular, you will avoid the bad habit of mixing view tier concerns into the adapter to your model tier code.
If you don't like XML configuration formats for navigation rules (I don't have a problem with them -- indeed, the fact that Struts *had* config files originally is one of the things that made it popular :-), the answer is a graphical tool that lets you draw the state chart diagram, and then just uses a faces-config.xml file as its persistence format. Sun Java Studio Creator does that for pure JSF navigation, for example. You can edit the raw XML if you really want to, but few people bother. Its much easier to drag a line from one page to another, and label it with an outcome, than it is to type in a navigation rule.
That kind of thing is a separate concept, and would be interesting to explore. You can already define wildcards in the "from" expressions of a navigation rule, and there are rules about the order in which patterns are tested, but they don't provide the explicit control over the search path that you are describing here. (But I'd still vote for encoding navigation in a config file, not in code :-).
Craig
Anyway, I checked out the extensions, and personally think they are
heavens sent, but in my opinion there is huge room for more.
What I really love about Seam and what is missing in the extensions is
an easy dialog mechanism. Currently you have to define your own dialog
flow in a file. Seam does it rather basic, and easy to understand with a
@begin and @end annotation marking the dialog flow borders, everything
in between is not interesting configurationwise.
Is there anything similar planned for Shale?
Not currently -- and I doubt I would be in favor of it anyway :-).
Annotations are absolutely fantastic for use cases where there is one and only one decision to make, and it would never be changed anyway because too much other stuff would break. Annotated managed beans are a perfect example of that ... the managed bean name gets baked into every value binding _expression_ that references that bean, and the choice of scope can dramatically affect how and wehre you encode functionality. So why risk having the configuration settings get out of sync because they are in a config file instead of the code?
Navigation is a different situation, however. I believe that the developer creating the backing beans, and therefore implementing the action methods, should be focused on communicating *outcomes* through the return values of the methods. They should describe "what happened" not "where to go next". The navigational aspect of this is up to the person who is architecting the overall navigation of the application, gluing it all together. Even if it is the same person doing both roles, you will improve the quality of your code by separating those concerns. In particular, you will avoid the bad habit of mixing view tier concerns into the adapter to your model tier code.
If you don't like XML configuration formats for navigation rules (I don't have a problem with them -- indeed, the fact that Struts *had* config files originally is one of the things that made it popular :-), the answer is a graphical tool that lets you draw the state chart diagram, and then just uses a faces-config.xml file as its persistence format. Sun Java Studio Creator does that for pure JSF navigation, for example. You can edit the raw XML if you really want to, but few people bother. Its much easier to drag a line from one page to another, and label it with an outcome, than it is to type in a navigation rule.
Also one room for improval might be an annotation or implicit navigation
handler which directs with an implicit return "nextPage"; onto a
nextPage.jsp/jsf if it can be located within a search path, unless it is
overridden by the config file. That would reduce the number of
navigational entries tremendously.
That kind of thing is a separate concept, and would be interesting to explore. You can already define wildcards in the "from" expressions of a navigation rule, and there are rules about the order in which patterns are tested, but they don't provide the explicit control over the search path that you are describing here. (But I'd still vote for encoding navigation in a config file, not in code :-).
Craig
