struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <br...@pontarelli.com>
Subject Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Date Wed, 17 Oct 2007 21:58:59 GMT

This gets tricky when handling extensionless URLs, but I think can be 
done. I think it will require some filter dispatcher work, but 
definitely possible....


-bp


Jim Cushing wrote:
> 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 <husted@apache.org> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message