Don Brown wrote:
On 11/2/07, Brian Pontarelli <[EMAIL PROTECTED]> 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:
http://code.google.com/p/smarturls-s2/wiki/TechnicalSpecification
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?
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
