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 <[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.
---------------------------------------------------------------------
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]
