First of all, I think Ted did a good job of getting a start on this. His proposal is a great start that would unify several misc things that really needed to be unified. (Especially for 2.1.x where it would be nice to have a unified approach to these things)
Secondly, our company does the exact same thing that Brian's in that we have standardized components and I would love to have an open source standard to use. However, is that part of what Ted created, or is this a separate proposal? I really like the idea of having one place for xml configuration, whether it be struts config overrides, JPA class definitions or what-not, but that seems like a separate issue from what Ted is proposing. Tom On 10/17/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > Looks good. I like the name and most of the concepts. Here's some > additional thoughts: > > 1. If no code component exists and a default is not available, the code > invocation can be completely by-passed and processing should proceed > with the view component handling. The caveat here is that this will > require adding a goal to support for messaging, localization and i18n, > since this is something that is currently cumbersome. > > Also, the default handling should be spelled out with Index actions and > all the URL nuances like trailing slashes and such. > > 1.1 I'd like to add in a componentization goal here. SmartURLs and > Vertigo are leveraging a file named META-INF/component.xml (inside JAR > files) to specify not only all the action packages and the result > locations for actions and views bundled inside JAR files, but also to > specify JPA domain classes and other configuration for the component. > This is HUGE for companies that like to build components and then just > drop them in to web applications. We have a number of these including > user admin, CMS, blogs, news, todo, etc. I think that expanding this > into the specification will help solidify that this architecture can be > done on Struts2 and that it is a goal of the project. > > > > Ted Husted wrote: > > Following up on suggestions made by Don and Brian, I'd like to propose > > that we draft a formal specification describing the logic to be used > > by the (deep-breath) "Able/Code Behind/Zero-Config/SmartURLs" plugin > > for 2.1. The purpose of the specification would be to better define > > what "backward compatibility" means, and also to encourage > > implementation of this pattern by other frameworks. > > > > Following is the beginning of an early draft of a proposed > > "view-behind" specification. (In case anyone is interested, I'm using > > the JSON-RPC specification format as a model.) If there is interest in > > this proposal, I'd suggest we decide whether to complete the > > specification as part of our documentation, or at some other location. > > Of course, people working with other frameworks > > (<cough>stripes</cough>) would be welcome to join in. > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
