Ted Husted wrote:
On Nov 1, 2007 10:21 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
I have written ~10 applications to date using it:
Yes, but we also need public example applications that demonstrate a
range of workflows.
Definitely.
If we want to mark something GA, it's important that developers like
Jeromy can build applications with it too. To learn another lesson
from Rails and .NET, we should not only release the code but a set of
best practices as to how to use the code.
Agreed.
For example, right now, the MailReader is using the bang (!) alias
syntax, so there are URIs like "update!input" that lead to a
update-input page. Is there a way to get rid of that inconsistency, so
all the URIs look the same, or do we need to implement a way for
update-input to resolve to Update.input()?
I've completely moved away from methods and bangs. It makes the code
more readable, and maintainable in my opinion and it reduces the
learning curve considerably.
* http://code.google.com/p/smarturls-s2/issues/detail?id=16
The "bang" inconsistency already confused me. (Admittedly, not
difficult to do!) I wondered why I couldn't redirect to another
namespace. When I came back to the application a few weeks later, I
realized I was trying to redirect to "update-input" instead of
"update!input". These are the little pain-points that cost us hours
and days of head-scratching.
I'm pretty sure that's because you are, like I am, deeply involved in
Struts2 and WebWork and had that mindset. Which will be something we'll
need to address with other folks coming on board with this stuff.
I think my point is that although it has some downsides, it is live in
production sites and is working. It obviously can use improvements, but
I tend to feel that it works and makes things simpler than using XML. I
don't see gaping holes that need to be addressed and from my
perspective, anything we might add would be niceties and enhancements,
not fundamental changes of direction.
Agreed. Everything I've found is already on the SmartURLs issue list,
and it's a very short list.
What's missing is usage examples, and especially an test-suite
application that exercises the key features. I nervously applied some
patches yesterday, and the reason I was nervous is that I didn't have
a good way to QA the changes.
Though, I do think that changing the way the Action packages are
specified, or adopting a hierarchal view of namespaces are still
significant changes. If this code were already released, those are
changes that would take us from 1.0 to 2.0. Likewise, a solution to
the redirect-after-successful-POST could also force a major version
change, even if it is not a "fundamental" change.
Some these would be backwards compatible. Searching a hierarchy is only
used when actions are missing. Therefore, if a production application is
using an older version you can upgrade and the only time hierarchies
will be used is if that application was missing an action or the user
typed in an invalid URL. So, the change would be a 200 instead of a 404.
Likewise, the redirect after post, depending on how it works, would only
kick in if you didn't have a result for an action. If the application is
using an older version and bug free in this area, it will never kick in.
Not too mention older apps use the annotations for redirects, which will
still be available.
The action package resolution change would be rather major, but that's
the only one I can see as an incompatible change.
I'm scared to sit on it too long.
IIt doesn't have to be long. How about just long enough to consider
the short-list of SmartURLs issues, add a test-suite application, and
see if we can lure guys like Jeromy on board? :)
Honestly, I feel we could have a 1.0 SmartURLs plugin for Struts 2.0
much sooner than we will ever have a Struts 2.1 release. And, I also
feel that we would have a Struts 2.1 sooner if we do the right thing
with SmartURLs now.
Okay, sounds good. I can bust out a full app with my best practices
pretty quickly. I'll add it to the project.
You know, in terms of moving this along, a test-suite application
might be even more important that a formal specification, since a
test-suite application could be used to demonstrate
backward-compatibility. I'm thinking of something like the taglib
"Exercise" application we have for Struts 1. It's not a cookbook or a
showcase, it's straight-up bare-bones tests that prove the tags work
as expected. Of course, the application is also defining our
expectations :)
I've stopped writing the specification, but I still think we should
eventually finish that. I'll switch to the application and go back to
the spec later.
Meanwhile, the very next thing on my list is a JPA SmartURLs
MailReader. If we really want to do ourselves a favor, we will be very
sure that our conventions mesh hand-in-glove with the JPA :)
Sounds good. My example will contain a CRUD or two as well. I'll might
use JPA, depending.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
