Seaside and REST
Locked
123
123
 
|
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 |
|
|
> * 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 ;-) The thing that Pier is doing in #initialRequest: has absolutely nothing to do with RESTful URLs. In Pier this method is used to setup the dynamic component tree specified in the environment page of the wiki. The thing that parses the URL is PRPierMain>>#start: and friends. While all this could be well done also in #initialRequest:, it is still there for historic reasons. What you have to have a look at is PRPierMain>>#updateRoot: and friends are the methods that generate the RESTful URLs. > 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? ;-) WABrowser > * 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. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Lukas Renggli wrote:
>> * 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 ;-) > > The thing that Pier is doing in #initialRequest: has absolutely > nothing to do with RESTful URLs. In Pier this method is used to setup > the dynamic component tree specified in the environment page of the > wiki. Sorry if I got this wrong - Philippe seemed to imply in his post that such a setup is done in #initialRequest: and I just didn't get what the code in PRPierFrame had to do with setting up REST urls ;-) > The thing that parses the URL is PRPierMain>>#start: and friends. Thanks, I will look at this. >> 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? ;-) > > WABrowser Yes, I had seen this but there were some aspects that weren't clear to me so I was wondering how they would be addressed in a real application (which also led me to PRPierFrame>>initialRequest: btw). >> * 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. If you think that there is something wrong with a basic assumption you should enlighten me. But the last time I checked, Seaside utilized HTTP and HTTP has some very clear rules (see [1]) which state explicitly: "In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested." State changes (like in the counter example) seem to signify "an action other than retrieval", no? Now, you may choose to ignore these rules but "SHOULD NOT" in an RFC has a much stronger meaning than "it's okay to ignore if you feel like it" [2]. That's why I've been asking the question. And I think the robots issue is a real one, too. Or do Seaside apps somehow, magically, never get indexed? Can they even be indexed in any meaningful way? Cheers, - Andreas [1] See http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1 [2] See http://www.ietf.org/rfc/rfc2119.txt SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> >> * 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. > 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 -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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 |
|
|
In reply to this post by Andreas.Raab
Hi Andreas,
on Thu, 29 Mar 2007 10:15:04 +0200, you wrote: > ... But the last time I checked, Seaside utilized HTTP and HTTP has some > very clear rules (see [1]) which state explicitly: > > "In particular, the convention has been established that the GET and > HEAD methods SHOULD NOT have the significance of taking an action other > than retrieval. Living on the side where the http logs are written, for something like a decade now, this statement clearly means resources like "document" content and is WebDAV minded, not to say file-oriented. Replacing a negotiable document resource by a server side script which responds what a related file resource would respond does not add much change that view. 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). Another illustrating use case is HTTP-tunneling. What method SHOULD they NOT use, POST or GET? IIRC they use both and the choice depends on what method allows *huge* amounts of bytes transfered upstream (POST) and what not (GET). [this is just from experience, no offense intended.] > These methods ought to be considered "safe". This allows user agents to > represent other methods, such as POST, PUT and DELETE, in a special way, > so that the user is made aware of the fact that a possibly unsafe action > is being requested." Then, how would you access a constantly changing "document" resource like a Croquet application running elsewhere, with HTTP. HTTP request methods where invented with "a resource is a file and the version and quality of the file's content can be negotiated by a HTTP method" in mind, IMO. Later then an oops happened and POST was added. Even later the philosophy of GET v.s. POST was invented. Just my 0.05 CHF. /Klaus _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Re: Seaside and REST
|
|
In reply to this post by Andreas.Raab
Umm, wouldn't you just avoid using anchor callbacks for things you don't want crawled? Its up to you as a developer to choose which element performs which function when you're putting your application together. If you follow the principle of using anchors for navigation and forms+buttons for modification you will get the effect you desire, not sure that seaside itself has to do much with the issue. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On 3/29/07 10:06 AM, "Boris Popov" <[hidden email]> wrote:
> Umm, wouldn't you just avoid using anchor callbacks for things you don't want > crawled? Its up to you as a developer to choose which element performs which > function when you're putting your application together. If you follow the > principle of using anchors for navigation and forms+buttons for modification > you will get the effect you desire, not sure that seaside itself has to do > much with the issue. Although I may be showing my ignorance of Seaside (I'm pretty new to it), I think this is just my point? If the framework allows destructive operations through links (anchor callbacks), the unsuspecting developer who doesn't understand the difference between links vs. forms+buttons will be caught unaware. I guess I am assuming that if a developer doesn't understand GET vs. POST, he also doesn't understand links vs. forms and the implications of crawlers. > > Cheers! > > -Boris > (Sent from a BlackBerry) > > ----- Original Message ----- > From: [hidden email] > <[hidden email]> > To: Squeak-Seaside <[hidden email]> > Sent: Thu Mar 29 04:42:26 2007 > Subject: Re: [Seaside] Re: 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 http://itsallsemantics.com "Hell, there are no rules here-- we're trying to accomplish something." -- Thomas A. Edison _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Re: Seaside and REST
|
|
In reply to this post by Andreas.Raab
Well that's right, who's to say that a GET to a PHP or Perl script won't do something destructive? Framework can only do so much, and its certainly up to develorers to try to make sure their application is crawlable if they care. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Klaus D. Witzel
Hi Klaus -
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? > Another illustrating use case is HTTP-tunneling. What method SHOULD they > NOT use, POST or GET? IIRC they use both and the choice depends on what > method allows *huge* amounts of bytes transfered upstream (POST) and > what not (GET). > > [this is just from experience, no offense intended.] None taken. That is a great question. What is "best practice" these days? Just use whatever you feel like? Whatever works most efficiently? >> These methods ought to be considered "safe". This allows user agents >> to represent other methods, such as POST, PUT and DELETE, in a special >> way, so that the user is made aware of the fact that a possibly unsafe >> action is being requested." > > Then, how would you access a constantly changing "document" resource > like a Croquet application running elsewhere, with HTTP. HTTP request > methods where invented with "a resource is a file and the version and > quality of the file's content can be negotiated by a HTTP method" in > mind, IMO. True, but for example, in Croquet we have that distinction constantly. We have, for example, a method #get: in code which (surprise!) is a pure retrieval, idempotent and safe ;-) And then we have future messages (think: POST) which modify the resource (object). And it makes perfect sense both conceptually as well as from a practical point of view. Cheers, - Andreas _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Daryl Richter-3
Yes, that's my point exactly. Being told "go away and use a different
framework" is about the least helpful answer one can get. If there are rules for when to use what I'd love to learn about them. Cheers, - Andreas Daryl Richter wrote: > On 3/29/07 10:06 AM, "Boris Popov" <[hidden email]> wrote: > >> Umm, wouldn't you just avoid using anchor callbacks for things you don't want >> crawled? Its up to you as a developer to choose which element performs which >> function when you're putting your application together. If you follow the >> principle of using anchors for navigation and forms+buttons for modification >> you will get the effect you desire, not sure that seaside itself has to do >> much with the issue. > > Although I may be showing my ignorance of Seaside (I'm pretty new to it), I > think this is just my point? > > If the framework allows destructive operations through links (anchor > callbacks), the unsuspecting developer who doesn't understand the difference > between links vs. forms+buttons will be caught unaware. > > I guess I am assuming that if a developer doesn't understand GET vs. POST, > he also doesn't understand links vs. forms and the implications of crawlers. > >> Cheers! >> >> -Boris >> (Sent from a BlackBerry) >> >> ----- Original Message ----- >> From: [hidden email] >> <[hidden email]> >> To: Squeak-Seaside <[hidden email]> >> Sent: Thu Mar 29 04:42:26 2007 >> Subject: Re: [Seaside] Re: 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 > _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Re: Seaside and REST
|
|
In reply to this post by Andreas.Raab
Andreas,
See my earlier messages. It's completely up to you, as you get to choose whether to use anchors (GET) or forms/buttons (POST) when you put your pages together. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Andreas Raab > Sent: Thursday, March 29, 2007 10:39 AM > To: Seaside - general discussion > Subject: [Seaside] Re: Seaside and REST > > Hi Klaus - > > 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, > > 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? > > > Another illustrating use case is HTTP-tunneling. What method SHOULD they > > NOT use, POST or GET? IIRC they use both and the choice depends on what > > method allows *huge* amounts of bytes transfered upstream (POST) and > > what not (GET). > > > > [this is just from experience, no offense intended.] > > None taken. That is a great question. What is "best practice" these > days? Just use whatever you feel like? Whatever works most efficiently? > > >> These methods ought to be considered "safe". This allows user agents > >> to represent other methods, such as POST, PUT and DELETE, in a special > >> way, so that the user is made aware of the fact that a possibly unsafe > >> action is being requested." > > > > Then, how would you access a constantly changing "document" resource > > like a Croquet application running elsewhere, with HTTP. HTTP request > > methods where invented with "a resource is a file and the version and > > quality of the file's content can be negotiated by a HTTP method" in > > mind, IMO. > > True, but for example, in Croquet we have that distinction constantly. > We have, for example, a method #get: in code which (surprise!) is a pure > retrieval, idempotent and safe ;-) And then we have future messages > (think: POST) which modify the resource (object). And it makes perfect > sense both conceptually as well as from a practical point of view. > > Cheers, > - Andreas > _______________________________________________ > 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 |
|
|
Boris Popov wrote:
> See my earlier messages. It's completely up to you, as you get to choose > whether to use anchors (GET) or forms/buttons (POST) when you put your > pages together. Thanks, stating the difference explicitly is very helpful. However, just trying it out by, e.g., WACounter>>renderContentOn: html html heading: count. html submitButton callback: [self increase]; text: '++'. html space. html submitButton callback: [self decrease]; text: '--'. does not seem to work, any ideas? Cheers, - Andreas _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Re: Seaside and REST
|
|
You need a form to put buttons in,
WACounter>>renderContentOn: html html form: [html heading: count. (html submitButton) callback: [self increase]; text: '++'. html space. (html submitButton) callback: [self decrease]; text: '--'] Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Andreas Raab > Sent: Thursday, March 29, 2007 11:23 AM > To: Seaside - general discussion > Subject: [Seaside] Re: Seaside and REST > > Boris Popov wrote: > > See my earlier messages. It's completely up to you, as you get to choose > > whether to use anchors (GET) or forms/buttons (POST) when you put your > > pages together. > > Thanks, stating the difference explicitly is very helpful. However, just > trying it out by, e.g., > > WACounter>>renderContentOn: html > html heading: count. > html submitButton > callback: [self increase]; > text: '++'. > html space. > html submitButton > callback: [self decrease]; > text: '--'. > > does not seem to work, any ideas? > > Cheers, > - Andreas > _______________________________________________ > 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 |
RE: Re: Seaside and REST
|
|
Before people chime in with 'links are easier to style than buttons', I
was in the same camp until YUI button control came out and our designer had a stab at it. Attached is a screenshot of 3 elements, anchor and two buttons (enabled and disabled states). As you can see they're fairly close, especially if you don't put them side by side. Until recently, we had to use pre-rendered imagery to achieve the same effect on buttons. More, http://developer.yahoo.com/yui/button/ Hope this helps, -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Boris Popov > Sent: Thursday, March 29, 2007 11:25 AM > To: Seaside - general discussion > Subject: RE: [Seaside] Re: Seaside and REST > > You need a form to put buttons in, > > WACounter>>renderContentOn: html > html > form: > [html heading: count. > (html submitButton) > callback: [self increase]; > text: '++'. > html space. > (html submitButton) > callback: [self decrease]; > text: '--'] > > Cheers! > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > http://tinyurl.com/r7uw4 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the message > header. Unless otherwise indicated, it contains information that is > private and confidential. If you have received it in error, please > notify the sender and delete the entire message including any > attachments. > > Thank you. > > > -----Original Message----- > > From: [hidden email] [mailto:seaside- > > [hidden email]] On Behalf Of Andreas Raab > > Sent: Thursday, March 29, 2007 11:23 AM > > To: Seaside - general discussion > > Subject: [Seaside] Re: Seaside and REST > > > > Boris Popov wrote: > > > See my earlier messages. It's completely up to you, as you get to > choose > > > whether to use anchors (GET) or forms/buttons (POST) when you put > your > > > pages together. > > > > Thanks, stating the difference explicitly is very helpful. However, > just > > trying it out by, e.g., > > > > WACounter>>renderContentOn: html > > html heading: count. > > html submitButton > > callback: [self increase]; > > text: '++'. > > html space. > > html submitButton > > callback: [self decrease]; > > text: '--'. > > > > does not seem to work, any ideas? > > > > Cheers, > > - Andreas > > _______________________________________________ > > 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 _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
yui.png (5K) |
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
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 |
|
|
On Mar 29, 2007, at 2007-03-29 Thu2:42 PM, Andreas Raab wrote: > Boris Popov wrote: >> You need a form to put buttons in, > > Dang! Of course, stupid me ;-) > > Thanks, > - Andreas It would certainly be nice if this produced an error message. Instead, everything looks right but it doesn't work. I have wasted time with this and I'm sure others have too. Rick _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Re: Seaside and REST
|
|
Might not be a bad idea, although strictly speaking you *can* have
button elements outside a form, so the following produces perfectly valid XHTML in and of its own even though it doesn't quite work the way you might expect it to, html heading: count. html submitButton callback: [self increase]; text: '++'. html space. html submitButton callback: [self decrease]; text: '--' Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Rick Zaccone > Sent: Thursday, March 29, 2007 11:50 AM > To: Seaside - general discussion > Subject: Re: [Seaside] Re: Seaside and REST > > > On Mar 29, 2007, at 2007-03-29 Thu2:42 PM, Andreas Raab wrote: > > > Boris Popov wrote: > >> You need a form to put buttons in, > > > > Dang! Of course, stupid me ;-) > > > > Thanks, > > - Andreas > > It would certainly be nice if this produced an error message. > Instead, everything looks right but it doesn't work. I have wasted > time with this and I'm sure others have too. > > Rick > > _______________________________________________ > 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 |
|
|
In reply to this post by Andreas.Raab
Hi Andreas,
on Thu, 29 Mar 2007 19:38:49 +0200, you wrote: > Hi Klaus - > > 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. NP, undo is only a local phenomenon and has nothing to with HTTP </grin> - http://www.google.com/search?q=undo+undone+site:www.w3.org > 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? Dunno. Seasiders? >> Another illustrating use case is HTTP-tunneling. What method SHOULD >> they NOT use, POST or GET? IIRC they use both and the choice depends on >> what method allows *huge* amounts of bytes transfered upstream (POST) >> and what not (GET). >> [this is just from experience, no offense intended.] > > None taken. That is a great question. What is "best practice" these > days? Just use whatever you feel like? Whatever works most efficiently? There are only two: crawlers (and bookmarked URLs, as mentioned by others already. both have the same "don't state me in" requirements) v.s. upstream request method capabilities and requirements - ignoring WebDAV (as usual :) FWIW upstream request method capabilities may also be constrained by the HTML author's taste and abilities, when for example using forms and their elements (may be circumvented by XMLHttpRequest-ing). And because of so many ( :) web "servers" buffer overflow vulnerabilities during request processing, GET requests nowadays are very limited [also: beware of the proxying middle man]. Needless to say, the restrictions make GET come closer to what W3 wants us to do with GET and all the files on our web server ;-) >>> These methods ought to be considered "safe". This allows user agents >>> to represent other methods, such as POST, PUT and DELETE, in a special >>> way, so that the user is made aware of the fact that a possibly unsafe >>> action is being requested." >> Then, how would you access a constantly changing "document" resource >> like a Croquet application running elsewhere, with HTTP. HTTP request >> methods where invented with "a resource is a file and the version and >> quality of the file's content can be negotiated by a HTTP method" in >> mind, IMO. > > True, but for example, in Croquet we have that distinction constantly. > We have, for example, a method #get: in code which (surprise!) is a pure > retrieval, idempotent and safe ;-) And then we have future messages > (think: POST) which modify the resource (object). And it makes perfect > sense both conceptually as well as from a practical point of view. I knew I was talking to an expert, Andreas :) Cheers Klaus > Cheers, > - Andreas _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Andreas.Raab
2007/3/29, Andreas Raab <[hidden email]>:
> 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? You mean that the default method of forms in Seaside is POST as in HTML and if you want them to use GET you have to tell them to use GET instead of POST? The default counter uses anchors which are GET - always - this is hardwired in HTML and can not be changed. > 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? 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. Philippe > Thanks, > - Andreas > _______________________________________________ > 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 |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |