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 Thu, 01 Nov 2007 20:43:36 GMT

First, just wanted to cover the plan quick. I was planning on merging 
the SmartURLs code into the existing codebehind plugin tomorrow and 
ensuring everything is correctly in the new packages and that the old 
annotations are correctly deprecated. Is this still how we want to move 
forward?


Second, some thoughts on the specification:

Section 5 was somewhat confusing. I had difficulty determining the 
meanings of terms used in section 5 during my first read. Some of them 
were later defined in the examples in section 5.1. Particularly 
code-suffix, was defined and then not used again until the examples. It 
was replaced with 'Code Component Suffix', which isn't in the 
definitions section. However, 'Code Suffix' was defined.

I would start off with detailed descriptions of the three strategies for 
action matching in section 5. These descriptions should use the 
definitions in section 4.

The examples are somewhat confusing because there isn't any definition 
about non-code-suffixed actions, which in the Struts case are determined 
via implementation of the Action interface. This should probably be 
spelled out is some type of action-type matching. #2 , #4 and #5 fall 
into this category.

Also, #5 needs an code-suffix variant. And #6 needs an action-type variant.

I would think that a scanning methodology would be best rather than just 
a fall back. Something like

/my/namespace/action
/my/action
/action

Also, transform-code-prefix and transform-code-name aren't defined 
anywhere and the only workflow that is spelled out is the Mapping Name 
transformation.

It seems like there is a change between capitalized definitions and 
their dash/lowercase versions, and sometimes they aren't consistent. I 
would define everything once using the dash version and ensure that all 
capital usages are replace accordingly. This will make it simpler to 
reference through out. You could also go with the capital versions and 
replace the dash versions. Either way should work, but the dash versions 
look better in the BNF.

Also, using the code blocks that Google Code provides colorizes 
strangely. It would probably be better to outline workflows as numbered 
lists. The BNF looks good in the code blocks but some are colorized and 
some aren't. This makes it difficult to pull out the BNF when scanning.

I'd also put in some mention that the heuristic can be handled on demand 
or pre-loaded. The way that the current workflows are presented it 
sounds like the code and results are only found on demand and not 
pre-configured to speed things up.

-bp


Ted Husted wrote:
> Just to followup, I setup a Google Code site as a place to describe
> and design cross-platform technologies that pertain to web application
> development and deployment. For some time now, I've spent half my time
> working in .NET, which probably won't change for another year or two,
> and so working on cross-platform technologies is of great interest to
> me.
>
> I've extended the initial draft posted here to include the action URI
> to Action Class mappings. While based on SmartURLs and CodeBehind, the
> description goes beyond what either can do right now.
>
>  * http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001
>
> Before doing any more work on the description, I'd be very interested
> on feedback as to whether I'm making any sense, or whether the draft
> has turned into opaque gibberish :)
>
> -Ted.
>
>
> On Oct 17, 2007 2:24 AM, 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.
>>     
>
> ---------------------------------------------------------------------
> 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