Re: Exploring actionPackage-based configuration issues

[Brian Pontarelli]

-bp


Eric D Nielsen wrote:

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. BTW, I added support for Namespace and ParentPackage at the package-info.java level. Also added the namespace parameter to the ActionName annotation per issue #4.

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;

my email.  Though, I'm not sure how beneficial it'll be.  Seeing how

so we wouldn't be introducing a new file just to hang the annotations on.




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 package hierarchy.


following a convetion like com.example.packages.foo.QuxPackage looks for

the configured default.


it easier for run-time reconfiguration of packages/actions.  Imagine for
instance that your building a application that builds some form of 'store

reaching....  Just not sure how far :)


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)


approaches for per XWork package configuration
a) existing struts.xml
b) adding annotations to package-info.java

class)


thing that I'd like the package to take care of for me yet.

Eric

Ahh, that's what I was referencing as a possible solution at the very bottom of 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 I've been wondering if a solution more like: (I'm not tied to any of the names, 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 Furthermore we could get parent-package auto-detection for nested packages com.example.packages.FooPackage to set as its parent package before failing to Now one advantage I can think of for this type of system, is that it might make 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 Annother feature that might make sense in the more programatic/annotation based However, I'm still not sold, on my own idea... It seems that there are three c) something like what I'm suggesting (promoting XWork packages to an explicit 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

smime.p7s
Description: S/MIME Cryptographic Signature