I think about annotations just like configuration files because their just meta-data. So, if I'm sitting down to crank out some actions, I think, "what can I do in this class to get it working?" I've got to think about the URL it will map to, the result of the invocation, validation, interceptors, etc.
Another decision is to whether or not the implementation of the API annotations should exist in core or as a plugin. If the API exists as a plugin, then since this is really a convention over configuration approach, I feel that the reference implementation should exist alongside it in the same plugin, making things as simple as possible and reduce the barriers to entry. However, if the API is part of core, then the reference implementation should be in core.
Now, I've also been thinking about consistency. If you define annotations and allow multiple implementations at all, you reduce the consistency of the API without a clearly define specification and rules about extension. (An example is J2EE clustering) That is, if I use the annotations in one project, they might behave drastically different than in another project. This reduces the overall convention based approach by causing some developers (i.e. consultants and the like) to become familiar with numerous implementations.
So, here's my thought... I think a standard plugin that is part of the main distribution might be best. This would contain all standard annotations and the main implementation for them. And, as part of the plugin we define good extension points to reduce the possible variations, but still allow changes. Then if folks want to completely change the conventions, they can create their own annotations and plugins and not cause too many conflicts. Also, I'd like to possibly pull in some of the JSRs as already mentioned. I think the validation annotations and a few of the others warrant some investigation.
-bp Ted Husted wrote:
If we are going to do major surgery on the annotations, then we should move them to a Struts Annotations plugin. In this way, we can bring out a new and improved annotations plugin for 2.1, and people can choose which set of annotations to use. We do already have some annotations in the public API, and giving people a choice between plugins is an excellent way to provide a migration path. Also, in that way, work on the new annotations won't hold up the rest of the 2.1. release. I would still like to roll 2.1.0 by the end of the month. I'm away next week, but perhaps we could plan on Sept 30 (unless someone else is available). -Ted. On 9/21/07, Ian Roughley <[EMAIL PROTECTED]> wrote:Don Brown wrote:In this case, the annotations will be likely redone for 2.1 anyways. A lot of it is my fault - they have been kinda thrown in there without systematic thought, and I had hoped we could fix that for 2.1. I'd hate to introduce new annotations only to deprecate them weeks later.My preference would be to wait as well. If for nothing else, to see how JSR-311 (RESTful web services) flushes out and whether we should adopt some of the structure of the annotations in Struts2. Has anyone looked into this JSR? I saw a presentation at Sun Tech Days the other day. I just need to find some time to see if it could be adopted to the annotations in s2 now :-)--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
