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.
Given the nature of the beast, I was thinking more along the lines that a code "component" would be required, and if no behavior was desired an do-nothing component could be provided by the application. I'd also suggest that features like messaging be considered out-of-scope and should be provided by the host framework. Though, going off topic a bit, in terms of Struts 2/XWork 2, I have been wondering if a POJO Action should need to provide an execute method (or other alias). An Action object could easily do whatever work is needed within a constructor, or at runtime during a method call. I glanced at the XWork code, and there seems to be an implicit assumption that some method be called when the Action class is invoked. Alternatively, if we could express "no execute method required", the system could inject "success" and move on. (And maybe issuing a log message in dev-mode.) But, again, that has nothing to do with the view-behind specification per se. > Also, the default handling should be spelled out with Index actions and > all the URL nuances like trailing slashes and such. Yep. Haven't gotten to the hoary details yet :) > > 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 It might be something to discuss for XWork, but as Tom says, it seems out of scope for the view-behind specification, and it might even be the stuff of a specification unto itself. Looking forward, for Struts and XWork, I'd suggest we try to stay aligned with OSGi for configuration issues. For view-behind, I'd like to stay to the high-ground and not assume a Java platform or Java semantics, since this technology is something that could be used by other platforms as well. (And in some form, already is!) -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
