Quoting Brian Pontarelli <[EMAIL PROTECTED]>:
You actually can annotate packages. There is a special java file
called package-info.java that you place in a package and annotate
like this:
@ParentPackage("foo")
package com.example.actions;
Ahh, that's what I was referencing as a possible solution at the very
bottom of
my email. Though, I'm not sure how beneficial it'll be. Seeing how
package-info.java is used primarily for JavaDoc needs, I'm not sure how clean
it is to start mixing in the configuration aspects. Yes the file
already exists
so we wouldn't be introducing a new file just to hang the annotations on.
I've been wondering if a solution more like: (I'm not tied to any of
the names,
optional/additional overrides should in brackets)
---------------------------------
package com.example.packages;
[EMAIL PROTECTED]("somename")]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
public class FooPackage [implements XWorkPackage] {
public Result login = new Result("login","redirect")...
// or maybe more like
@Result(...)
public String login="login";
@Interceptor(order=["top"|"bottom"|?] // refering to before/after the
pre-configured stack?
public String someMethod(ActionInvocation invocation) throws Exception {
}// assumes that the interceptor doesn't need an init/destroy
}
----------------------------------
package com.example.actions.foo;
public class BarAction [implements Action]
...
-----------------------------------
package com.example.actions;
public class BazAction [implements Action]
....
-----------------------------------
Actions in actions.foo would have their ParentPackage set to the FooPackage by
default, (and could always override with their own explciit
ParentPackage. I'm
not sure how to deal with properly un-aliasing camelCapped Packages
from nested
subpackages, etc. The @DefaultPackage annotation is used to set an
application
wide default and to specify the parent package of actions at the root of the
actions package hierarchy.
Furthermore we could get parent-package auto-detection for nested packages
following a convetion like com.example.packages.foo.QuxPackage looks for
com.example.packages.FooPackage to set as its parent package before failing to
the configured default.
Now one advantage I can think of for this type of system, is that it
might make
it easier for run-time reconfiguration of packages/actions. Imagine for
instance that your building a application that builds some form of 'store
fronts'. When a client signs up, they app creates a new package for them and
copies some stock actions into their section of the site, etc. I can tell I'm
reaching.... Just not sure how far :)
Annother feature that might make sense in the more
programatic/annotation based
appraoch:
a series of naming strategy methods (like hibernate's) for changing the
capitalization/hyphenation rules for mapping urls to actions within that
package, or mapping results to content directory(^Hies)
However, I'm still not sold, on my own idea... It seems that there are three
approaches for per XWork package configuration
a) existing struts.xml
b) adding annotations to package-info.java
c) something like what I'm suggesting (promoting XWork packages to an explicit
class)
As I see it, Struts 2 will need at (a) and at least one of (b)&(c). To my
thinking, if there is at least one more useful
programatic/instrospection based
thing to hook on the explicit class approach, its probably a winner. But I
haven't dug deep enough into a real application to know if there's another
thing that I'd like the package to take care of for me yet.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
