Quoting Brian Pontarelli <[EMAIL PROTECTED]>:
I guess I'm missing the overall use case. Do you just want to get rid
of all your XML configuration and put everything inside Java code and
annotations? Or are you trying to solve a specific problem that is
currently unsolvable? It seems like it is more of the former because
right now, with a hybrid of XML and annotations you should be able to
handle most cases.
I'm happy with a hybrid mix of XML and annotations; however something
feels very
wrong about using the package-info.java file for holding the XWork
package level
annotations, so I'm trying to think of alternatives.
My alternative approach was trying to explore what value could be added by
exposing the XWork package as java object; and yes I'm failing currently to
find value.
I think the root problem is that I'm not 100% comfortable with model of the
XWork Package. As I see it so far, its a container for configuration
information and for some reason that bothers me. I feel that there is an
application developer-exposed class waiting to be discovered. This is
probably
more of a struts 2.1++ issue, but I think the notion of an XWork package is
missing something. (It might also be advisable over several releases to
consider renaming the XWork package concept so its not as confusable with the
java package, but that's an orthogonal issue.)
This feeling of unease is slightly exacerbated by some of the difficulties I
have debugging package issues -- ie when playing with zero configuration
annotations and xml, there's does seem to be any good way to check what
package
an action has been assigned to confirm that defaults or annotations are
working.
config-browser exposes the namespace of an action, but not its package, for
instance. This leads to the feeling that the XWork package is a second-class
citizen in the framework, but I know its not.
While I can see wanting some configuration control over the package --
changing
namespaces; or the root of web content, in the case of SmartURLs; changing
naming strategies -- feel like proper "configuration" tweak points (and thus
more XML friendly). Ie these are things that I'd expect good default
coventions for, but things that in best practices are overridden in
XML. Things that you want to be able to change on multiple-deployments
without
re-compiling.
While the other aspects -- interceptors, names and types (but maybe not
destination) of global results, which actions belong to this package, etc are
"configuration" but not really end-user configuration. Its the wiring that's
not expected to be changed. This is places where good conventions overridden
by source code annotations makes the more sense. And at which point
having the
ability to programaticly configure an application starts to feel possibly
valuable.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
