Hi,
I've browsed through the examples included with Seaside. I'm at a loss to think of things that would take advantage of Seaside's continuation-based nature. What web applications are there worth building that have the kind of complex control flow which necessitate the use of a framework like Seaside? Warren Henning _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> Hi,
> > I've browsed through the examples included with Seaside. I'm > at a loss to think of things that would take advantage of > Seaside's continuation-based nature. > > What web applications are there worth building that have the > kind of complex control flow which necessitate the use of a > framework like Seaside? > > Warren Henning Anything with a complex workflow. Seriously, take a look the sample store's checkout process, and consider what this might look like in a traditional framework. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Warren Henning
> I've browsed through the examples included with Seaside. I'm
> at a loss to think of things that would take advantage of > Seaside's continuation-based nature. > > What web applications are there worth building that have the > kind of complex control flow which necessitate the use of a > framework like Seaside? Gosh...what web application, other than serving static pages, *wouldn't* be easier in Seaside? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 9/5/06, Kurt Thams <[hidden email]> wrote:
> Gosh...what web application, other than serving static pages, *wouldn't* be > easier in Seaside? As I see it, you pay a price when you use Seaside. You get ugly URLs that can't be hacked off to navigate with. The simple fact is users use URLs as a user interface element. In exchange for a usability hit you'd better be delivering an experience that's impossible to create with Rails et al. Seaside is most appropriate where it doesn't make sense to bookmark and navigate in a page-oriented manner. Warren _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> On 9/5/06, Kurt Thams <[hidden email]> wrote:
> > Gosh...what web application, other than serving static pages, > > *wouldn't* be easier in Seaside? > > As I see it, you pay a price when you use Seaside. You get > ugly URLs that can't be hacked off to navigate with. The > simple fact is users use URLs as a user interface element. In > exchange for a usability hit you'd better be delivering an > experience that's impossible to create with Rails et al. Impossible to create with Rails? I don't see the tradeoff that way. (1) The URLs issue is a tiny hit in usability; most people want to bookmark entry points into an application, not every page inside it. This is *especially* true of dynamic websites. Do you bookmark the page that confirms your shipping address in a web shopping application? (2) Seaside makes it really, really easy to develop applications that work much more the way a user thinks. (Including: using the "Back" and "Forward" buttons doesn't get the state all goofed up). This usability enhancement alone more than makes up for the URL look problem, IMHO. (3) In Seaside, it is so much easier to develop applications, as compared to any other platform that I've seen. That *really* makes it a big win for me. Sorry if my users don't get natty URLs, but there are some applications I just wouldn't have bothered writing if I had to slog through any other framework. (4) Debugging is dramatically easier than debugging from other systems. Really. (If anyone can describe another system that is comparable, I'd like to know it). What I'd suggest is that you try writing a simple application (or work through some of the tutorials and then expand on their examples). My guess is that in short order, you will find yourself creating complex, functioning web sites that take you a tiny-tiny-tiny amount of time to get developed and debugged! I'll grant that Ruby on Rails is pretty sweet if you are doing an application that displays and edits columnar data taken from an RDB, but I suspect that sooner or later that same kind of functionality will get built into Seaside. Question for the community: Could the URL-based state mapping be addressed some other way? (This has probably already been taken up here; if so, sorry). _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question for the community: Could the URL-based state mapping be
addressed some other way? (This has probably already been taken up here; if so, sorry). See this link, http://www.lukas-renggli.ch/smalltalk/seaside/presentation/06.pdf http://seaside.st/Documentation/NamingURLs/ Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [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:[hidden email]] On Behalf Of Kurt Thams Sent: Tuesday, September 05, 2006 10:50 AM To: 'The Squeak Enterprise Aubergines Server - general discussion.' Subject: RE: [Seaside] Seaside project ideas? > On 9/5/06, Kurt Thams <[hidden email]> wrote: > > Gosh...what web application, other than serving static pages, > > *wouldn't* be easier in Seaside? > > As I see it, you pay a price when you use Seaside. You get > ugly URLs that can't be hacked off to navigate with. The > simple fact is users use URLs as a user interface element. In > exchange for a usability hit you'd better be delivering an > experience that's impossible to create with Rails et al. Impossible to create with Rails? I don't see the tradeoff that way. (1) The URLs issue is a tiny hit in usability; most people want to bookmark entry points into an application, not every page inside it. This is *especially* true of dynamic websites. Do you bookmark the page that confirms your shipping address in a web shopping application? (2) Seaside makes it really, really easy to develop applications that work much more the way a user thinks. (Including: using the "Back" and "Forward" buttons doesn't get the state all goofed up). This usability enhancement alone more than makes up for the URL look problem, IMHO. (3) In Seaside, it is so much easier to develop applications, as compared to any other platform that I've seen. That *really* makes it a big win for me. Sorry if my users don't get natty URLs, but there are some applications I just wouldn't have bothered writing if I had to slog through any other framework. (4) Debugging is dramatically easier than debugging from other systems. Really. (If anyone can describe another system that is comparable, I'd like to know it). What I'd suggest is that you try writing a simple application (or work through some of the tutorials and then expand on their examples). My guess is that in short order, you will find yourself creating complex, functioning web sites that take you a tiny-tiny-tiny amount of time to get developed and debugged! I'll grant that Ruby on Rails is pretty sweet if you are doing an application that displays and edits columnar data taken from an RDB, but I suspect that sooner or later that same kind of functionality will get built into 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 |
On Sep 5, 2006, at 11:01 AM, Boris Popov wrote: > Re: Question for the community: Could the URL-based state mapping be > addressed > some other way? (This has probably already been taken up here; if so, > sorry). Hey Boris, Can you elaborate on that? Like, which goal you're trying to achieve that the current approach doesn't allow, or isn't easy enough for? Avi _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Oh I think it works perfectly well, I was responding to Kurt's original
question on how this could be done in Seaside. Outlook doesn't do quoting like other (read: sane) clients, so I just copied the question over to the top of the message. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [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:[hidden email]] On Behalf Of Avi Bryant Sent: Tuesday, September 05, 2006 11:00 AM To: The Squeak Enterprise Aubergines Server - general discussion. Subject: Re: [Seaside] Naming URLs (Was: Seaside project ideas?) On Sep 5, 2006, at 11:01 AM, Boris Popov wrote: > Re: Question for the community: Could the URL-based state mapping be > addressed > some other way? (This has probably already been taken up here; if so, > sorry). Hey Boris, Can you elaborate on that? Like, which goal you're trying to achieve that the current approach doesn't allow, or isn't easy enough for? Avi _______________________________________________ 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 Kurt Thams
> Question for the community: Could the URL-based state mapping
> be addressed some other way? (This has probably already been > taken up here; if so, sorry). Have a look at Pier (written in Seaside of course), it has bookmarkable URL's. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Boris Popov, DeepCove Labs (SNN)
On Sep 5, 2006, at 11:06 AM, Boris Popov wrote: > Oh I think it works perfectly well, I was responding to Kurt's > original > question on how this could be done in Seaside. Outlook doesn't do > quoting like other (read: sane) clients, so I just copied the question > over to the top of the message. Ah, I see. Sorry. I should note that those docs you linked to are somewhat out of date - usually all you should have to do now to handle extra URL params is override #initialRequest: on your root component. Cheers, Avi _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Could somebody add that to the FAQ :)
Stef >> Oh I think it works perfectly well, I was responding to Kurt's >> original >> question on how this could be done in Seaside. Outlook doesn't do >> quoting like other (read: sane) clients, so I just copied the >> question >> over to the top of the message. > > Ah, I see. Sorry. > > I should note that those docs you linked to are somewhat out of > date - usually all you should have to do now to handle extra URL > params is override #initialRequest: on your root component. > > Cheers, > Avi > _______________________________________________ > 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 Kurt Thams
Kurt Thams wrote:
> I'll grant that Ruby on Rails is pretty sweet if you are doing an > application that displays and edits columnar data taken from an RDB, but I > suspect that sooner or later that same kind of functionality will get built > into Seaside. > Wasn't this done already? I would almost swear I have seen a seaside project that did the same thing as RoR? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Jason Johnson wrote:
> Kurt Thams wrote: >> I'll grant that Ruby on Rails is pretty sweet if you are doing an >> application that displays and edits columnar data taken from an RDB, >> but I >> suspect that sooner or later that same kind of functionality will get >> built >> into Seaside. >> > > Wasn't this done already? I would almost swear I have seen a seaside > project that did the same thing > as RoR? > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > seaside? What about DabbleDB? Can't that do some database imports and things? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On Sep 8, 2006, at 7:13 AM, Jason Johnson wrote: > > So I take it, no one can think of something close to Ruby on Rails > for seaside? What about DabbleDB? Can't that do > some database imports and things? Dabble is an end-user product, not a framework you can use with Seaside, and it uses its own internal database, not an RDBMS. Cheers, Avi _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |