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.
I can understand the difficultly in using a new language concept that has
little mindshare but I think that this is the standard location for
that kind of configuration according to the Java language. Besides,
this is the only clean way to ensure a single location of package
level annotations and documentation.
Yes, you're right. I had just read some faulty tutorials explaining that new
feature only in the context of the "new" JavaDoc convention. I didn't
see that
it was added precisely for this type of use.
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.)
I definitely agree on the whole naming issue. It is difficult to talk
to new developers about XWork packages without confusion. Are you
suggesting that the XWork package needs more configuration control or
that the concepts
need to be separated or something else entirely? You sorta lost me here.
I sorta lose myself here too, that's the problem. An XWork package
doesn't seem
to exist, other than ethereally. See below, since I think my
explanation makes
more sense in context with your next response.
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.
This is an interesting dilemma because the way XWork is configured implies
reuse at the Action level and that Actions should not be coupled to
the interceptor chain (to some degree). However, this is usually not
the case. Most Actions I write are highly dependent on the
interceptor chain and nearly never dependent on the namespace and
often never reused (that's what I usually place in the service tier).
However, most times it is a
95%/5% situation where I use the same interceptor chain for 95% of
the application and a different chain for 5% (or less). Therefore,
global defaults usually work best for me.
This might not the norm, but my experience to date with 5 or so
applications. Therefore, setting good global or XWork package
defaults makes sense to me.
Not sure what I'm getting at but it seems that the current
configuration model makes good sense and works for all the cases I've
had.
In my admittedly limited experience, I tend to agree. The original
problem that
sparked this thread was that, outside of SmartURLs, there doesn't seem to be
good support (or documentation if there is support) for setting application
level defaults. And this support really should be in core, regardless of the
plugin landscape.
Back to the general philosophical issue: If I'm reading your response
correctly,
it sounds like your basically saying that good defaults + per action
annotation
overrides covers almost all of your needs. This to me, starts to make
it sound
like the XWork package is a useless construct. Or its bundling the
wrong items
at the wrong level to allow the re-use it should.
It feels like while an XWork package might be an internal XWork
abstraction, its
not one that should be exposed to the application developer -- some other
configuration/"action-configuration-template" mechanism should be
created. What it should look like, I'm not sure. It feels like we'd
like to be able to
define global interceptor stacks as non-package contained entities, we'd like
to do the same for global results. We'd like to be able to set a defined
global interceptor stack as the default stack. Now there will be times
when we
have some variants (your 5%) -- often alot of these will be singletons, each
different in their own way, but we probably still have a few clumps that need
identical tweaks ... this is where the XWork package concept could be useful,
possibly even as is, if the global/application-wide setup worked,
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.
Hmmmmm... I personally don't like the idea of changing namespaces or naming
strategies at all. If you consider SEO, this is usually a bad idea
unless you are really good about retaining existing URLs and doing
proper 301 redirects. Otherwise, you'll upset the search gods and
your ranking will drop considerably, not to mention the 3 months
you'll have to wait to get re-ranked. Also, since I'm not huge on
Action reuse, I'm perfectly
fine setting namespaces using Java packages or annotations. And in my
opinion, naming strategies should be fixed from the start and never
changed.
I'd agree that naming strategies/etc should not be changed once the
application
reaches production. However I expect there to be a lot of flux in initial
development. Or if you're writing a "commodity web-app", for there to be
possibly significant deployment time tweaks to integrate with existing other
apps.
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.
I'm sorta on the other side of the fence here. I don't really change
interceptor chains too much and often when I do, changing the whole
application is fine by me. Or if I need to change a single package,
that's okay in XML or the properties file as well. Global results and
package results are also usually a one time configuration for me and
not
something that Actions really need to know about. So, I usually find
that I set these up in the struts.properties and struts.xml files and
never touch them. So, having these defined in annotations is really
not something I use much, if at all.
I guess in the end, I'm fine with the way it all works now. I rarely
hit a configuration problem that I just feel bad implementing using
the current
tools and often I tweak at the beginning and then never touch it again. But
again, this is my cases and I'm sure folks do it other ways. I guess
I'm just wondering what really seems to be your ideal
configuration/coding solution, what configuration should Actions be
aware of and what are
you looking to control?
Well Struts + SmartURLs gets close to my ideal. I'll have better insight into
the any problem points, for me, once I get further into my application. As I
see it there are three current problems
1) config-browser doesn't show the action's package, so debugging why actions
aren't configured as expected can be hard
2) setting appropriate defaults at application level, appears
impossible without
certain plugins, or not documented
3) "proliferation" of plugins -- I'm very worried by the discussion I've seen
about plugins versus core versus standard zip file. I was driven away from
Rails after ~2 years over this issue. There, the core liked to push everyhing
out from core into plugins, leading to increasing number of plugin conflicts
that never really got addressed. Yes it makes life easier for both core and
plugin developers, but it means framework users have to deal with endlessly
reconcilling/locally patching plugin interaction problems. A lot of plugins
are "experimentation" in my opinion -- searching for the right way to extend a
framework (look at Zero Config, Code-Behind, and SmartURLs) -- and once the
"solution" (or partial union of solutions) is found, it should be rolled into
the core.
(Sorry point 3 is a hot-button of mine, didn't really want to get into it, but
it does bear directly on this issue)
I think it looks like Zero Configuration was rolled into core
prematurely? Since the existing XWork package configuration works fine
if you're only using
struts.xml and not using conventions/annotations. If you're using
conventions/annotations that's when the inability to set the default package,
etc rears its ugly head.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
