On Thu, Jul 10, 2008 at 10:36 AM, Alan Gutierrez <[EMAIL PROTECTED]>
wrote:
>
> Out of line. My apologies. From all I've read of you you're an expert
> and extremely well qualified. What's wrong with me? Sorry. Totally
> classless and I'm pleased to meet you.
I'll be first to say I'm not an expert, but I'm also not a n00blet wanting
to add all shiny things I see. Apology accepted and nice to meet you too. :)
> I suppose I've developed a deep seated fear that my new favorite
> framework will go the way of Cocoon or Wicket and wanted to argue
> loud and hard against performing the ritual where an open source
> framework embraces, extends and extinguishes itself.
Understandable, if I was involved in a framework that killed itself from
bloat I would probably have the same fear of that myself.
>
> So, if it's not in the core, which upon more careful reading, I see
> it is not, then I'm not feeling personally threatened by REST, but it
> still strikes me as a silly exercise. The verbs buy you little.
>
> They came in handy with WebDAV which wanted to hide the verb because
> it didn't want to clutter up the URL. That's fine for WebDAV clients
> and WebDAV servers. But the concept of representing state in a URL is
> just that.
>
> I don't see how this HTTP verb thing works really? Because if it's my
> little web protocol that serves my little XML files the way Flickr,
> Amazon WS, and Google Geocoder do, then I don't see why I can't send
> a query string, and bonus if I can send only a query string and not
> have to send a verb, because then I can test using my browser's
> address bar.
>
If all you have is browser interaction with your webapp, then I can agree to
a point where REST might be overkill and not needed at all. But when using
almost any HTTP library you have access to tell what type of request to
send, so whats easier? Rember the specific event name for the server to do
something( x 4 for each action x <How many different types you have>) or
simply call remember 4 verbs for everything. YES this can be worked around
by common/sane event names, and I would argue it should be done that way
anyways, REST or no REST, but how many programmers have the consistency to
do that?
>
> Which means that to address the problem of providing simple access to
> raw data using HTTP protocols, the verb thing makes it more
> complicated. If the end goal is to create an easily documented API
> that people can "mashup" then playing around with HTTP verbs means
> that you've got more splanin' to do. I don't see how it's useful,
> unless you want to implement a WebDAV server using Stripes, which is
> about the only use for it. With WebDAV they were developing a
> protocol, but if you want to attract mashups, use POST and GET.
Depends on how you look at it. You'll also have to explain what events do
what when I send a request to your App as well. Right?
> > To date, my experience with Stripes is that the documentation talks
> > about the things that I can use and want to use and do use. Stripes
> > itself is free of flights of fancy. I'm using Stripes and Stripersist
> > and it's a complete framework.
> >
> > I agree, we use stripes here mostly for what it DOESN'T do, not
> > because it has the most shiny objects in it. It does what it does
> > well and thats it. You think I want to turn Stripes into the next
> > JSF or whatever? No thanks,
>
> The glorious thing about Stripes is that the page at
> stripesframework.org pretty much tells it all.
>
> > My only disappointment is that I'd like to have a lot more control
> > over the URLs. That's a more important component of Basic/Core/Pure
> > HTTP than the strange stumpy tail or 6th finger of the HTTP verb.
> >
> > Well you should have that already with the more friendly URL stuff
> > in 1.5, no need to concern yourself with that stumpy 6th finger if
> > you don't want.
>
> Actually, the biggest thing that Stripes could to to support REST or
> rather mashable HTTP APIs (MashHAPI?) would be to work on the URL
> dispatching. I was not able to do the following with the Stripes 1.5
> and had to work around.
>
> @UrlBinding("/{account}/users/{user}")
> public class AccountUserActionBean
> implements ActionBean
> {
> }
>
> Maybe I missed something, but looking at the code, I couldn't find it
> and had to roll my own work around.
Can't comment on this unforutanetly as I haven't had a real change to fully
use the new urlbinding stuff. :(
> --
> Alan Gutierrez | [EMAIL PROTECTED] | http://blogometer.com/ | 504
> 717 1428
> Think New Orleans | http://thinknola.com/
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Stripes-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
