Craig McClanahan schrieb:
On 1/17/06, *Werner Punz* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
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?
ok point taken...
Snip
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 :-).
Well the way I see it it is not really code but more an implicit default
behavior, which you can override by xml. That way you would not loose
the control over your xml entries but you can cut down on them
significantly.
Wildcards are very powerful but not quite as compact as an implicit
mapping, which can be overridden ;-).
