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
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. 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. Don On 10/18/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. > > > > ---- > > > > View-Behind Specification > > Working Draft 17 October 2007 > > > > Previous Versions: > > None > > Editors: > > Ted Husted, Husted.com > > <Others TBD> > > > > This document is currently a working draft published with the intent > > of soliciting community feedback. Please send your comments and > > concerns to the public mailing-list <TBD>. > > > > This specification is designed to provide the developer with the > > information needed to implement the technology within a web > > development framework for any platform. > > > > > > 1. Overview > > > > "View-behind" is a technology that combines intelligent defaults, > > convention over configuration, and annotation, in order to streamline > > web application development. Larger applications tend to the separate > > the concerns of "business logic" and "display logic" into different > > components. View-behind works to assemble these concerns back into a > > single request/response transaction, without requiring redundant > > metadata descriptions. > > > > By leveraging intelligent defaults, convention over configuration, and > > annotation, page-behind elimates the need for XML metadata, helping > > applications become easier to write and review. The view-behind naming > > conventions are designed to be "Search Engine Optimized", and the > > view-to-code matching conventions observe existing class naming > > conventions. > > > > In a view-behind workflow, the client requests a virtual "action" URI, > > which the system maps to an optional code component. (In a Java > > implementation, a code component would be a Java class.) If there is > > no code component, a default component is utilized. The code is > > invoked, and the system selects a view component (e.g. JSP) based on a > > heuristic that utilizes the original action name and any special > > outcome provided by the code at runtime. > > > > Optionally, metadata, in the form of annotations or XML documents, may > > be used to override the components usually mapped to an action URI. > > Common application workflows can be realized without resorting to > > metadata. > > > > Optionally, in a HTTP environment, parameters to the action request > > may be presented in a "RESTful" format that utilizes slashes rather > > than the usual HTTP "?" and "&" semantics. > > > > The moniker "view-behind" is suggested since the pattern links to > > actions which then automatically select views "behind the scenes". > > View-behind differs from Code-Behind > > (http://support.microsoft.com/kb/303247) in that links are to virtual > > URIs, rather than physical files, and that a different view component > > may be selected depending on the outcome of invoking the code at > > runtime. > > > > > > 1.1. Goals > > > > The primary goals of this specification are to define the view-behind > > technology in terms of: > > > > * Mapping an action URI to a code component. > > * Mapping a runtime code outcome to an a view component. > > * Overriding the default component mappings with metadata. > > * Mapping RESTful URIs to conventional parameterized URIs. > > > > > > 1.2. Non-Goals > > > > View-behind does not address issues such as validation, security, > > session management, or the generation of a response to common errors, > > such as "File not found". Developers are expected to utilized existing > > features found in the underlying platforms to implement such features. > > > > > > 1.3. Limitations > > > > TODO > > > > > > 2. Differences From Prior Versions > > > > None. > > > > > > 3. Requirements > > > > The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, > > SHOULD NOT, RECOMMENDED, MAY and OPTIONAL in this document are to be > > interpreted as described in RFC 2119. > > > > An implementation is not compliant if it fails to satisfy one or more > > of the MUST requirements for the patterns it implements. An > > implementation that satisfies all of the MUST and all of the SHOULD > > requirements for its features is said to be unconditionally compliant; > > one that satisfies all of the 'must' requirements but not all of the > > SHOULD requirements for its features is said to be conditionally > > compliant. > > > > > > 4. Terminology > > > > Below is a summary of some terminology used in this documentation that > > can help in disambiguation of commonly applied and therefore often > > overloaded terms: > > > > Action Request/Response > > A named operation supported by the application that expects zero > > or more input parameters and ultimately returns a response to the > > client, usually in the form of a HTML page > > > > Client > > The agent that initiates the action request and receives the action > > response > > > > Code Component > > A software component that executes business logic or data access > > logic as part of the > > client's request > > > > System > > The software component (e.g. web application framework) that > > implements page-behind. > > > > View Component > > A page template or similar component that is responsible for > > rendering a response to client's request > > > > > > 5. Selecting a Code-File (Action Request) > > > > TODO > > > > > > 6. Selecting a Page-File (Action Response) > > > > TODO > > > > > > 7. Processing a Request/Response > > > > TODO > > > > > > 8. Utilizing Optional Metadata (Annotations or XML) > > > > TODO > > > > > > 9. Parsing RESTful parameters > > > > TODO > > > > > > 10. Naming Artifacts (actions, results, parameters) > > > > ---- > > > > Thoughts? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
