[Please excuse if this appears twice, the copy I sent several hours ago seems to have gotten lost and my webmail client does drop emails at times]
>> 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]
