Ted Husted wrote:
On Nov 1, 2007 5:02 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
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?
Personally, I'd like to see three different applications written
entirely with the conventions, before I'd be comfortable calling
anything like this stable. Good examples might be the MailReader, the
ShowCase, and a Struts Petstore.
I have written ~10 applications to date using it:
http://www.inversoft.com (to be launched with Vertigo in the next few weeks)
http://www.mocapay.com
http://www.ireland-stapleton.com (to be launched next week)
http://www.pentaxian.com
http://www.texturemedia.com
and a few other public applications that I can't recall off the top of
my head and 3 or so internal applications.
I've also built 3 components using it, a CMS component, News component
and User component. All of these components are being used in the above
sites.
The point of the exercise is to make it easier to write applications.
The one and only way for anyone to know if this stuff actually works
is to eat our own dog food, and put it to work. Not just on what we
are doing in-house, but on public examples, that we ourselves did not
contrive, and that other people can review and dissect.
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.
Looking at the latest SmartURLs MailReader (r119),
* http://people.apache.org/~husted/mail-reader-0.19-SNAPSHOT.war
the biggest pain-point is redirects, and nothing we've done so far is
addressing that concern.
Agreed. This one could use some thought, but there is currently a
solution that is still less headache than XML. Once we have a better
solution it will simply make things even easier.
I'm sure we won't be able to solve the problem of when and where to
redirect 100% of the time, but if we can use conventions even 80% of
the time, we're starting to save actual effort.
Perhaps, but this might be understating the number of possibilities.
The common use case for redirecting is to redirect after a
(successful) POST, mostly because we don't want them to resubmit
again, and also because it usually signals the end of a workflow, and
implies it's time to return to a menu or some other parent workflow.
The POST part we could trap one way or another. The hinky part is
where the redirect should go (at least by default).
Yeah, that's the trick. I need to think on it, but I'm sure we could
come up with something.
Now, as Brian mentioned, something else we haven't been doing is
considering the namespaces an actual heirarchy. In both Struts 1 and
Struts 2, the slashes are just characters, and the namespace is just a
string. But, what if we adopting the convention of nesting namespaces
to represent parent/child hierarchies. For example, in the MailReader,
that would mean that instead of "register" and "subscribe" namespaces,
we should have "register" and "register/subscribe", or even
"/menu/register/subscribe".
If we consider namespaces a hierarchy, and we adopt the convention of
honoring Index pages, then a likely default behavior after a
successful POST might be to redirect to "../Index", or to the first
"higher" Index we find.
Again, "redirecting up after post" won't eliminate the need to
annotate redirects, but it may decimate the need.
Could work, but I have a feeling there might be something even better.
Just need to have it pop into someone's head at some point.
Of course, there are other pain-points in the MailReader, and I'm sure
we'd find others in new implementations of the ShowCase and Petstore.
But, the point of the plugin and the spec should be to identify what
actually helps us write various applications ... and trying to lower
our tolerance to pain :)
I'm not sure I think that it is as much pain as you. I see XML as like a
10 and what we have currently as like a 3. I've gotten used to thinking
in actions and results. I've gotten away from things like using the
action-input urls and worked on more rails like standards. I've tried to
ignore result codes whenever possible and use action names for results.
Things like that. I find that my pain points are less SmartURLs, but
more tricky HTTP/web situations that arise no matter what you are using.
Overall, my own preference would be to first finish what we've started
with the SmartURLs plugin for Struts 2.0.x. When we can use it to
write the simplest possible MailReader, ShowCase, and Petstore, then
let's make bring it onboard as the new CodeBehind for Struts 2.1.x. If
there's something that the CodeBehind does that SmartURLs doesn't do,
then let's port that functionality over.
I'm scared to sit on it too long. I'm using it in so many places
already. The more I want to start frameworking around Struts2 the more
I'd like a permanent place for this code. Vertigo (Struts2, Guice,
Hibernate, JPA, scaffolding, emailing, security, ecommerce, file
management, AJAX, etc) is nearing public release point and I'd hate to
have a huge API change after I start doing releases for that and start
evangelizing it. On that note, I'm fine just continuing to develop
SmartURLs and keep things where they are, but I don't really want to
have two competing code bases and dead project situations.
As to the generic specification, for the last two years, I've spent
half my time working in .NET, and it looks like that will be the
status quo for at least a couple of years more. I'm really liking the
heuristic mappings strategy, and, regardless of what else is
happening, I'll be implementing a .NET version that we can use at
work.
I'm in a very similar situation and have a number of ideas for making
.Net frameworks like Struts, if I ever get sometime. I think a generic
approach is fine, but I'd rather go generic after we solidify the
Java/Struts version and iron out the last of the decisions.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
