Ted Husted wrote:
On 8/2/06, Don Brown <[EMAIL PROTECTED]> wrote:
Patrick and I talked about doing that, however, we came up against
several
roadblocks:
1. How would you handle nested packages? For example: /foo/bar/joe?
Do we need to handle nested packages?
In webwork I make use of nested packages.
2. How would you handle action methods?
In the scope of convention over configuraion, I'd suggest that we
don't utilize multiple action methods. I'm coming to the conclusion
that multiple aliases on an action is not a good practice, much like
chaining actions is not a good practice.
If we adopt the perspective that one-method per action is the
cannonical norm, then everything falls into place. The key trouble
with one-method per action is it increases the number of similar
action mappings to maintain. But between wildcards, an extends
feature, and annotations, that problem goes away.
This is actually a feature that I like in WW/SAF, granted some times is
makes more sense to use it than others, but that is always going to be a
design decision. Can you further explain why you have come to the
conclusion that they are not good practice?
3. The case might not always match
Hmmm, I thought the whole idea behind convention over configruation is
that we *make* these things match because they are *suppose* to match.
One possible solution would be to introduce "wildcard modifiers" that
would let
you modify the wildcard-matched value. For example, in problem #3,
you would
want to have "foo/bar" used for the action class "com.acme.{1}.{2}".
You could
apply a modifier like so - "com.acme.{1}.{2|capitalize}" - which would
capitalize the Action name. The idea from these modifiers comes from
Javascript
Templates [1].
The modifiers could solve problems 3 and maybe 1
("com.acme.{1|slashesToDots}.{2|capitalize}"), and perhaps #2 could
be solved by
using the "!" separator instead of the "/" again.
However, the question must be raised whether these improvements
obscure the
somewhat advanced wildcard capability. There is a danger in being
too fancy for
your own good, resulting in a feature that is perceived as too
complicated and
detrimental to the framework. Whether that applies here is up for
discussion.
I'd agree that supporting all fancy alternatives is not a good idea.
The goal should be to solve use cases, not cater to every whim about
what should be upper or lower case.
People who want to fine-tune this sort of thing can use configuration
over convention. Convention over configuration should be for people
who are actually willing to follow a convention.
And, if we use wildcards to define a default convention, there would
be nothing preventing someone from defining another wildcard
convention, suitable to specific needs.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
