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]
