I think this is an excellent idea. I also think Stripes has done an excellent job of implementing this and allowing easy overriding with Java code (for extensions and such).
Matt On 10/17/07, Tom Schneider <[EMAIL PROTECTED]> wrote: > 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] > > -- http://raibledesigns.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
