On 10/17/07, Don Brown <[EMAIL PROTECTED]> wrote: > Hmm..I'm a bit leary about this "component" talk. I'd like to keep > Struts 2 simple and I see the goal of this is to define a plugin that: > * Builds configuration based on annotations > * Defines default results when none specified
In the specification, "component" is just a synonym for file, class, PHP script, whatever. We should add that to the vocabulary section :) By design, the specification is meant to be Struts and Java-agnostic. > Things I see out of scope: > * A new component model > * REST support, particularly for Restful urls > > I interpret the "code component" in the spec to simply be an Action > and the "view component" to be a Result. Anything more than that > should definitely not go in core and its out of scope for this plugin. > > I list Rest support as out of scope, because it involves more than a > simple mapper. I'm working on a Rest plugin right now, and found it > needs code that would be inappropriate for non-Restful applications. > Trying to be all things to all people just complicates your code and > is more confusing to users. OK. I'd agree that RESTful parameters are a stretch. Without being implementation specific, there's probably no much to document there anyway :) > In the end, I'm happy to have a codebehind plugin that incorporates > more SmartURL code, particularly its additional lookups and > annotations, but again, I think it should be very simple and > straightfoward. Trying to define a new component model abstraction is > better served for another, more ambitious plugin. Again, that wasn't the intent of the "C" word :) The point of the proposed specification is not to invent anything, but rather to document things that are already invented, in such a way that other workers can implement the same technology on another platform. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
