struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Date Thu, 01 Nov 2007 22:02:50 GMT
Don Brown wrote:
> On 11/2/07, Brian Pontarelli <> wrote:
>> I think we might have slightly different ideas, but in general I imagine
>> everyone is pretty much inline and flexible enough to accept ideas from
>> others. I'll bang out the spec today and tomorrow and then see where we
>> are at. I'll put that in a wiki page over at the SmartURLs and build on
>> the abstraction that Ted started.
> That's the trick of writing against an evolving interface spec - your
> implementation is never done until the spec is finished. In this case,
> it is a spec against a spec :)
Yeah, tricky. hehe

> Here is the problem I've having - we are writing a book, and since
> this whole issue seems far from resolution, we've been using the XML
> configuration throughout the book (it is almost done).  What I'd
> rather have done is use the convention stuff to cut the code size and
> complexity of the examples down, which, IMO, would have made it easier
> to learn.  Therefore, I'd like to get this resolved asap.
Okay, let's do it. I should be able to have a good grasp on the exact 
requirements and proposals for the new plugin tomorrow morning. Here's 
what I've started:

> I'll try to find some time to review Ted's proposal, but if he is
> aiming to get other frameworks involved, it might be a while till it
> is done.  In the meantime, do you feel SmartURLs is exactly what you'd
> want the new plugin (or updated codebehind plugin) to look like, or
> are there features you would change/cut?  If you want it the way it
> is, we can use its docs as the spec and start the discussion there.
> Having used SmartURLs for a while now, having read Ted's spec, having
> spend some time thinking about the topic, I'd be curious to see how
> you think it should be done, as if starting from scratch.
I think there are two changes I'm going to make:

     1. Remove smarturls.action.packages and replace this with 
smarturls.action.package.identifiers, which is the list of identifiers 
that package names must contain. This would default to 
"action,actions,struts,struts2". This would require two annotations and 
two properties to turn specific packages on and off.

    2. Remove the component.xml file handling for components and rely on 
the changes in #1 to find actions and result locations for components.

This would make it simpler to start working and create java-packages 
that contain actions. Plus, it would support all the component 
infrastructure that I need in a completely standard fashion.

Besides that, I feel that everything else is fine and all we would be 
adding would be features. Nothing else really needs to be completely 
changed, but these two changes would impact applications that are 
already built on SmartURLs and codebehind.

So, if I bang out this specification, which would include the existing 
functionality with the changes above and a few other things I want to 
add in terms of features (i.e. searching / interceptors / defaults / 
exceptions / etc), would you feel comfortable writing the book against that?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message