This is just so I don't forget to mention it, but at one point Don was talking about having a built-in mechanism for handling various mimetype results (csv, pdf, etc.) via an action extension; I'd like to make sure that doesn't get lost in the shuffle, either via an "end of the url" param (foo/csv, foo/view/1/pdf, etc.)
Dave --- Ted Husted <[EMAIL PROTECTED]> 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 === message truncated === --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
