For different renderings/mimetypes, I think it'd make sense, if
possible, to use a dot-extension (e.g., "foo.pdf" instead of "foo/
pdf"), since this is a common and well understood convention.
On Oct 17, 2007, at 5:21 PM, Dave Newton wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
