Seaside and REST

> On 3/29/07 5:03 AM, "Lukas Renggli" <[hidden email]> wrote:
>
> >>>> * GET vs. POST: One of the things that confused me about the simple
> >>>> counter example already is that it uses POST instead of GET - isn't GET
> >>>> supposed to be idempotent as well as not modifying the requested
> >>>> resource?
> >>>
> >>> Frankly, if you are thinking about URLs and POST vs. GET, you should
> >>> probably not use Seaside.
> >>
> >> Frankly, giving a non-answer like this isn't exactly helpful.
> >
> > Seaside is for people that don't want to worry about low level details
> > such as HTTP. It let them think about more important things when
> > building a sophisticated application. Again if you want to fiddle
> > around with URLs and worry about HTTP details you probably should use
> > a different framework.
> >
> > Have a look at #navigation in WAAnchorTag. It creates an idempotent
> > (navigational) action callback for anchors.
> >
> >> question. And I think the robots issue is a real one, too. Or do Seaside
> >> apps somehow, magically, never get indexed?
> >
> > You see, Seaside is for sophisticated web *applications* and not web
> > *sites*. Does it make sense to index an application like Microsoft
> > Word? I doubt so.
>
> Ah, but if they are on the internet, they *will* be indexed.
>
> In the early days of Ruby on Rails framework development there was a a bit
> of angst since the framework initially performed deletes using links that
> used GET.  People put their sites up, Google "indexed", bye-bye data.

> So, while I totally agree that people creating a web site w/ Seaside
> shouldn't need to know about GET, POST, &c., the developers of the framework
> certainly should understand and use HTTP methods appropriately.
>
> >
> >> Can they even be indexed in any meaningful way?
> >
> > They certainly can, ask Google what it knows about my Pier site:
> >
> >      http://www.google.com/search?hl=en&q=+site:www.lukas-renggli.ch
> >
> > Cheers,
> > Lukas
>
> --
> Daryl
>
> "Don't worry about people stealing an idea. If it's original, you will have
> to ram it down their throats."
>     -- Howard Aiken
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Hi Folks -
>
> I've been toying around with Seaside and there are quite a few things
> that I don't understand. Since I've been spamming the Squeak list
> already with some of these questions I figure it's probably about time
> to move the discussion to this list. Here we go:
>
> * RESTful URLs: Philippe pointed me to http://www.lukas-renggli.ch/blog/
>   which discusses the use of RESTful URLs in Pier. Looking at it I found
> the dazzlingly cryptic method PRPierFrame>>initialRequest: and gave up
> on the idea for the time being ;-)
>
> Could someone perhaps give a brief outline of what needs to be done to
> support RESTful URLs in Seaside that both, goes well beyond "it can be
> done" and stays well short of PRPierFrame's implementation? ;-)
>
> * GET vs. POST: One of the things that confused me about the simple
> counter example already is that it uses POST instead of GET - isn't GET
> supposed to be idempotent as well as not modifying the requested resource?

> Can someone explain to me why Seaside uses GET for such requests and not
> POST? What rules does Seaside have for using GET vs. POST? What happens
> if a robot ever comes across the counter example?
>
> Thanks,
>    - Andreas
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Philippe Marschall wrote:
> > Anchors are GET, always. That has nothing to do with Seaside but with
> > HTML. Forms are default POST and GET if requested. Same as in HTML.
> >
> > I really fail to see the problem there, Seaside behaves exactly like
> > HTML which is not surprising since it uses HTML.
>
> Thanks. I think I got a little bit taken away with the whole "it's got
> nothing to do with urls/http/html" speech ;-) Since I don't know the
> whole of W3Cs specs at heart it wouldn't have surprised me to find out
> that there is some magic hidden inside seaside that makes it happen.

> Boris Popov wrote:
>> You need a form to put buttons in,
>
> Dang! Of course, stupid me ;-)
>
> Thanks,
>   - Andreas
>
>> WACounter>>renderContentOn: html
>> html
>> form:
>> [html heading: count.
>> (html submitButton)
>> callback: [self increase];
>> text: '++'.
>> html space.
>> (html submitButton)
>> callback: [self decrease];
>> text: '--']
>> Cheers!
>> -Boris
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Todd Blanchard
> Sent: Thursday, March 29, 2007 4:18 PM
> To: Seaside - general discussion
> Subject: Re: [Seaside] Re: Seaside and REST
>
> So seaside is a great application for people who don't want to care
> about low level details like http and html - except when you need to
> know about low level details like http and html.  :-)
>
> Abstractions leak more on the web than in most places.
> -Todd Blanchard
>
> On Mar 29, 2007, at 11:42 AM, Andreas Raab wrote:
>
> > Boris Popov wrote:
> >> You need a form to put buttons in,
> >
> > Dang! Of course, stupid me ;-)
> >
> > Thanks,
> >   - Andreas
> >
> >> WACounter>>renderContentOn: html
> >> html
> >> form:
> >> [html heading: count.
> >> (html submitButton)
> >> callback: [self increase];
> >> text: '++'.
> >> html space.
> >> (html submitButton)
> >> callback: [self decrease];
> >> text: '--']
> >> Cheers!
> >> -Boris
> >
> > _______________________________________________
> > Seaside mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Klaus D. Witzel wrote:
>> Besides of that, the counter in the Seaside counter example is  
>> *not* stored (as would be suggested by POST) but it is  
>> incremented. Doing incremental changes to a living object is not  
>> addressed by any HTTP request method ;-) For example, all WebDAV  
>> resources and Web2Mail scripts are considered to be dead (in the  
>> sense of a stateless, always repeatable request+response scenario).
>
> Which indeed they are. Buy my point about the counter example went  
> of course a little deeper. I can see the counter as stateless  
> merely by assuming that we have a platonic space of integer numbers  
> where plus and minus are retrievals ;-) However, that gets really  
> hard when we get to persistent state that can't be undone easily.  
> Or when one deals with files directly. Does Seaside have "special  
> rules" for making such modifications or are all of these presented  
> as GET nevertheless?

> Colin Putney wrote:
>> Hope this help with your decision,
>
> Yes, indeed it does. I think I'll try a mix-and-match approach and see
> where this gets me: Use HV2 for the RESTful parts and Seaside for the
> more complex ones. If it ends up all being Seaside in the end (or all
> being HV2) that's fine - for now I like to be able to try out both
> approaches and delay any irrecoverable decisions for a while. I think
> there is room for both in what I'm doing and learning about the
> strengths and weaknesses of each approach can't hurt.

> Philippe Marschall wrote:
>> We suck at documentation and getting started. We know that and are  
>> not
>> proud about this. We know the store example sucks. What would help  
>> are
>> easy ways to turn mails like this into useful documentation. And of
>> course if people help with documentation ...
>
> One of the things that I have done in the past is to, instead of  
> responding on-list, work information like this directly in a Wiki  
> that you refer people to. This has two advantages: First, the  
> information is preserved automatically, second, after a while  
> people learn that this is a good place to go look for answers.
>
> [--- big snip; wearing my flame-proof suit now ---]
>
> BTW, I can tell you in numbers how much Seaside sucks for  
> documentation - I noticed the apparent lack of any comments in so  
> much of the code so I wrote a little analysis tool which looks at  
> both class and method comments, ran this over my image, and took  
> out everything that is less than 50 classes. The result (in  
> alphabetical order so as not to embarrass you right away ;-) is this:
>
> Category Classes Comments    % Methods Comments   %
> Chat-* 50 12 24.00 584 151 25.85
> Collections-* 86 71 82.55 2009 1200 59.73
> Croquet-* 254 225 88.58 4599 1857 40.37
> Games-* 95 43 45.26 1114 198 17.77
> Graphics-* 57 46 80.70 1827 1085 59.38
> Kernel-* 81 72 88.88 3171 2172 68.49
> Magritte-* 214 83 38.78 1742 117 6.71
> Monticello-* 135 10 7.40 1502 70 4.66
> Morphic-* 419 255 60.85 10546 5037 47.76
> Multilingual-* 85 37 43.52 715 182 25.45
> Network-* 148 94 63.51 1512 728 48.14
> Pier-* 157 46 29.29 1227 154 12.55
> Qwaq-* 235 204 86.80 3746 2057 54.91
> QwaqDemo-* 89 80 89.88 967 488 50.46
> Scriptaculous-* 74 3 4.05 690 172 24.92
> Seaside-* 297 40 13.46 2809 126 4.48
> Sound-* 71 39 54.92 1252 615 49.12
> ST80-* 72 58 80.55 1447 1030 71.18
> Swazoo-* 81 1 1.23 718 45 6.26
> System-* 123 72 58.53 2125 1218 57.31
> Tools-* 60 42 70.00 1550 969 62.51
> Tweak-* 563 281 49.91 9432 4743 50.28
> VMMaker-* 93 71 76.34 3230 1488 46.06
>
> If you sort this a little (I'd love to use dabbledb for this but I  
> haven't figured it out yet ;-) you'll find that Seaside scores the  
> 4th to last rank when looking at percentage of classes commented,  
> and rock-bottom for percentage of methods commented. Ouch.
>
> [BTW, the best commented web package is HV2 but it is so small (44  
> classes) that it isn't listed here. It has 72% class and 53% method  
> comment coverage which is a fair bit above average]
>
> The code for the above analysis is attached.
>
> Cheers,
>   - Andreas
> <SystemDictionary-commentCoverageForon.st>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Hi!
>
>> Colin Putney wrote:
>>> Hope this help with your decision,
>>
>> Yes, indeed it does. I think I'll try a mix-and-match approach and see
>> where this gets me: Use HV2 for the RESTful parts and Seaside for the
>> more complex ones. If it ends up all being Seaside in the end (or all
>> being HV2) that's fine - for now I like to be able to try out both
>> approaches and delay any irrecoverable decisions for a while. I think
>> there is room for both in what I'm doing and learning about the
>> strengths and weaknesses of each approach can't hurt.
>
> I will send you write access to the HV2 repo. Don't hesitate to improve on
> it. :)