Yes, Web Velocity would have been well suited for that. And Randal
has a copy :) James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Jul 24, 2008, at 10:38 AM, James Foster wrote: > I'd like to thank all of you for your interest and support as we > prepared for this competition. Now for the report... > > Overall I'm disappointed with my performance. 20 minutes is just too > short a time for building even a trivial application using GLASS. > The analogy that comes to mind is this competition (race) was a > sprint and we are much better suited to competing in a marathon. > There was a point a couple days ago when I told people that we'd do > better if we got a beta copy of Cincom's Web Velocity from James > Robertson and used it for the competition. I think they (Cincom) are > doing an excellent job at aiming at this sort of audience. > > James Foster > > On Jul 16, 2008, at 2:46 PM, Kyle Dawkins wrote: > >> Hey Seasiders >> >> The RoR folks are running this at OSCON: >> >> http://pdxfoscon.org/competition >> >> Probably a good opportunity to show-off what Seaside can do. I >> can't attend so I can't volunteer but presumably since they mention >> Seaside and Gemstone, there are some people already signed up in >> the Seaside camp? Yes, yes, it's a silly contest (and proves very >> little), but could result in a few heads turned in our direction, no? >> >> I'd love to watch this... hopefully someone will provide a >> screencast at some point?! >> >> Cheers >> >> Kyle >> [hidden email] >> >> _______________________________________________ >> 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 |
>>>>> "James" == James Robertson <[hidden email]> writes:
James> Yes, Web Velocity would have been well suited for that. And Randal has James> a copy :) I was thinking it would be funny if I pulled out my laptop and started from scratch with WV while the GS team was competing. :) The real problem seemed to be that there's a lot of code to type to describe the meta data (Magritte)... but once that code is typed, lots of things are available in very flexible ways. The other frameworks essentially intermix metadata and uses of that data, and would spend a lot longer to *change* the result once built. And we all know, the majority cost of software is not initial development, but *maintenance* in reaction to changing minds^Wgoals of the customer. For example, had the contest been to start with your already built application and then simply *add* the rating, the GS team would have been done in 3 minutes, while the other teams (I suspect) would have taken longer, especially to figure how how to migrate their persistent schemas. Also, James Foster - you gotta learn to use a code browser that has ecompletion. I just started using one, and it's amazingly cool. It would have cut your typing time in half, likely. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by jgfoster
Hi James, how did the others frameworks do in the contest?
-Conrad On Thu, Jul 24, 2008 at 7:38 AM, James Foster <[hidden email]> wrote: I'd like to thank all of you for your interest and support as we prepared for this competition. Now for the report... _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by jgfoster
2008/7/22 James Foster <[hidden email]>:
> > I think I need these extensions to get the "Are you sure?" JavaScript. I > couldn't find a way to get a MACommandCollumn to add the #'onClick:' to the > anchor. (In a similar way, I think I need the PRDocumentComponent to render > the Wiki markup. It seems like this capability should have been available > already but I couldn't find it.) > Here the simple class which draws a dialog using lightbox. Just add a method , like this: confirmDialog: aTitle with: aContentsBlock ^ self lightbox: (TheDialogWindow confirmDialog: aTitle with: aContentsBlock) and then you can use it like this: html submitButton value: 'Delete this worthless stuff'; callback: [ (self confirmDialog: 'Deleting worthless stuff' with: [:htm | htm text: 'Do you really think this stuff is worthless?'] ) ifTrue: [ self deleteStuff ] ]. Note, that you can put any html inside a dialog window. Try it out :) -- Best regards, Igor Stasenko AKA sig. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside TheDialogWindow.st (3K) Download Attachment |
On Jul 24, 2008, at 8:51 AM, Igor Stasenko wrote: > 2008/7/22 James Foster <[hidden email]>: > >> >> I think I need these extensions to get the "Are you sure?" >> JavaScript. I >> couldn't find a way to get a MACommandCollumn to add the >> #'onClick:' to the >> anchor. (In a similar way, I think I need the PRDocumentComponent >> to render >> the Wiki markup. It seems like this capability should have been >> available >> already but I couldn't find it.) >> > > Here the simple class which draws a dialog using lightbox. > > Just add a method , like this: > > confirmDialog: aTitle with: aContentsBlock > ^ self lightbox: (TheDialogWindow confirmDialog: aTitle with: > aContentsBlock) > > and then you can use it like this: > > html submitButton value: 'Delete this worthless stuff'; callback: [ > (self confirmDialog: 'Deleting worthless stuff' with: [:htm | htm > text: 'Do you really think this stuff is worthless?'] ) > ifTrue: [ self deleteStuff ] > ]. > > Note, that you can put any html inside a dialog window. > > Try it out :) > > -- > Best regards, > Igor Stasenko AKA sig. > <TheDialogWindow.st> That does look nice, though I believe it does require execution of server code to handle the dialog. What drove me to do the extension was the "requirement" to use JavaScript so that the server code only ran if the user confirmed based on code running only on the client. James _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Conrad Taylor
On Jul 24, 2008, at 8:34 AM, Conrad Taylor wrote:
James
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by jgfoster
2008/7/24 James Foster <[hidden email]>:
> > On Jul 24, 2008, at 8:51 AM, Igor Stasenko wrote: > >> 2008/7/22 James Foster <[hidden email]>: >> >>> >>> I think I need these extensions to get the "Are you sure?" JavaScript. I >>> couldn't find a way to get a MACommandCollumn to add the #'onClick:' to >>> the >>> anchor. (In a similar way, I think I need the PRDocumentComponent to >>> render >>> the Wiki markup. It seems like this capability should have been available >>> already but I couldn't find it.) >>> >> >> Here the simple class which draws a dialog using lightbox. >> >> Just add a method , like this: >> >> confirmDialog: aTitle with: aContentsBlock >> ^ self lightbox: (TheDialogWindow confirmDialog: aTitle with: >> aContentsBlock) >> >> and then you can use it like this: >> >> html submitButton value: 'Delete this worthless stuff'; callback: [ >> (self confirmDialog: 'Deleting worthless stuff' with: [:htm | htm >> text: 'Do you really think this stuff is worthless?'] ) >> ifTrue: [ self deleteStuff ] >> ]. >> >> Note, that you can put any html inside a dialog window. >> >> Try it out :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> <TheDialogWindow.st> > > That does look nice, though I believe it does require execution of server > code to handle the dialog. What drove me to do the extension was the > "requirement" to use JavaScript so that the server code only ran if the user > confirmed based on code running only on the client. > Well, i really don't think that validating forms using javascript is good way. Because it is not secure, and often you need more additional data to validate an input, which accessible only at server side and hidden from client's eyes. Oh, and btw: good user interface should not show any 'yes-no' dialogs :) UI should be built on a principle which allows user do things first, without asking 'yes-no' all the way around, and then allow to revert things back (undo) at any the moment when he finds he made wrong action(s). > James > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On Jul 24, 2008, at 3:41 PM, Igor Stasenko wrote: > 2008/7/24 James Foster <[hidden email]>: >> >> On Jul 24, 2008, at 8:51 AM, Igor Stasenko wrote: >> >>> 2008/7/22 James Foster <[hidden email]>: >>> >>>> >>>> I think I need these extensions to get the "Are you sure?" >>>> JavaScript. I >>>> couldn't find a way to get a MACommandCollumn to add the >>>> #'onClick:' to >>>> the >>>> anchor. (In a similar way, I think I need the PRDocumentComponent >>>> to >>>> render >>>> the Wiki markup. It seems like this capability should have been >>>> available >>>> already but I couldn't find it.) >>>> >>> >>> Here the simple class which draws a dialog using lightbox. >>> >>> Just add a method , like this: >>> >>> confirmDialog: aTitle with: aContentsBlock >>> ^ self lightbox: (TheDialogWindow confirmDialog: aTitle with: >>> aContentsBlock) >>> >>> and then you can use it like this: >>> >>> html submitButton value: 'Delete this worthless stuff'; callback: [ >>> (self confirmDialog: 'Deleting worthless stuff' with: [:htm | htm >>> text: 'Do you really think this stuff is worthless?'] ) >>> ifTrue: [ self deleteStuff ] >>> ]. >>> >>> Note, that you can put any html inside a dialog window. >>> >>> Try it out :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> <TheDialogWindow.st> >> >> That does look nice, though I believe it does require execution of >> server >> code to handle the dialog. What drove me to do the extension was the >> "requirement" to use JavaScript so that the server code only ran if >> the user >> confirmed based on code running only on the client. >> > > Well, i really don't think that validating forms using javascript is > good way. Because it is not secure, and often you need more additional > data to validate an input, which accessible only at server side and > hidden from client's eyes. > > Oh, and btw: good user interface should not show any 'yes-no' > dialogs :) > UI should be built on a principle which allows user do things first, > without asking 'yes-no' all the way around, and then allow to revert > things back (undo) at any the moment when he finds he made wrong > action(s). > -- > Best regards, > Igor Stasenko AKA sig. And if you were invited to a Ruby event and asked whether Seaside/ Magritte could support JavaScript, would you tell them that they were wrong for asking? James _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
>
> And if you were invited to a Ruby event and asked whether Seaside/ > Magritte could support JavaScript, would you tell them that > they were > wrong for asking? > > James Nope, but I wouldn't be showing them Magritte either, that's a mistake, I'd be showing them Seaside and Scriptaculous. Magritte is complex in the same way Glorp is complex, building all those metadata descriptions is complex and error prone and takes way too much time to use in a demo, especially a time limited one. Whipping up something in raw Seaside would be much faster unless you've rigged up some code generators to write the mappings automatically for you. Rails guys are accustomed to ActiveRecord and scaffolding which bootstraps them up to a running system very quickly using code generation and a generate and modify philosophy (this is also how they learn Rails). Gemstone might eliminate the need for ActiveRecord, but Magritte is not at all equivalent to scaffolding. Scaffolding is much easier to hack and customize because it's not a framework, it's just a bunch of generated form template code. To compete against Rails in a time limited demo, you'll need something like a scaffolder, or a form builder you have a very deep knowledge of so it can be highly customized on the fly. To sell newbs, you need the scaffolder, because scaffolding code is an excellent way to teach them how to write Seaside code, they don't need yet another framework (Magritte) to learn. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On Jul 24, 2008, at 5:54 PM, Ramon Leon wrote:
>> >> And if you were invited to a Ruby event and asked whether Seaside/ >> Magritte could support JavaScript, would you tell them that >> they were wrong for asking? >> >> James > > Nope, but I wouldn't be showing them Magritte either, that's a > mistake, I'd > be showing them Seaside and Scriptaculous. Magritte is complex in > the same > way Glorp is complex, building all those metadata descriptions is > complex > and error prone and takes way too much time to use in a demo, > especially a > time limited one. Whipping up something in raw Seaside would be > much faster > unless you've rigged up some code generators to write the mappings > automatically for you. I did try it both ways and building the editor by hand seemed to be more lines of code and I thought I'd go for something that might seem more familiar for the domain definition. Also, since I was building one component by hand trying the other as meta data seemed like reasonable variety. On the other hand, since I don't consider the whole experience a great success I certainly won't insist that I made the right choice. > Rails guys are accustomed to ActiveRecord and scaffolding which > bootstraps > them up to a running system very quickly using code generation and a > generate and modify philosophy (this is also how they learn Rails). > Gemstone might eliminate the need for ActiveRecord, but Magritte is > not at > all equivalent to scaffolding. Scaffolding is much easier to hack and > customize because it's not a framework, it's just a bunch of > generated form > template code. To compete against Rails in a time limited demo, > you'll need > something like a scaffolder, or a form builder you have a very deep > knowledge of so it can be highly customized on the fly. To sell > newbs, you > need the scaffolder, because scaffolding code is an excellent way to > teach > them how to write Seaside code, they don't need yet another framework > (Magritte) to learn. Agreed. Maybe next time I'll channel the better-known "James" and try a demo of Web Velocity! > Ramon Leon > http://onsmalltalk.com James Foster _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
I do want to add that I was sitting in the audience and there was a lot of interest and discussion about what is happening with Maglev and the benefits that come with tools such as GemStone/S. I think people were not exactly sure of the process for building a solution using Seaside; this was, of course, a poor format for learning Seaside because there was no time for James to explain and type at the same time and stop for questions. Also, it is a very different set of tools and development process. But, when I started telling them that persistence just "is" and you don't have to do what I did earlier that day in my day job, that is, trying to marshall complex ruby objects into SQL, then their ears perked up. With commentary from Randal and comments from Monty, I think people learned a bunch. There were definitely some people that left with a whole new way of looking at the world.
James, I thought you did a great job, and I was really honored that you would be a part of the competition. I hope you were able to have fun and enjoy it, or at least can be relieved it is now over. Next year perhaps we'll do what you've all suggested: we can ask people to come with a completed application and then say "Now you have twenty minutes to make these five changes" and really let people see the power of Seaside that comes when you refactor an existing application. I say that as a impartial observer and not as an official organizer of the event of course! Chris On Thu, Jul 24, 2008 at 9:10 PM, James Foster <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Are there Pragma in Gemstone ? If yes I'll suggest looking at
SSFormand SSFormTest in Ramon image (http://onsmalltalk.com/downloads/DevImage.zip)... Otherwise, I think one could publish in a repository a small table component that add/edit/remove collection entries (based on conventions on object accessors) having a simple validate function ;)... There's a need anyway for such a component. It could even be a project in itself to expose several variations of tables... without any apriori relation to the oscon app :) My 2 cents Cédrick >> On Jul 24, 2008, at 5:54 PM, Ramon Leon wrote: >> >>>> >>>> And if you were invited to a Ruby event and asked whether Seaside/ >>>> Magritte could support JavaScript, would you tell them that >>>> they were wrong for asking? >>>> >>>> James >>> >>> Nope, but I wouldn't be showing them Magritte either, that's a mistake, >>> I'd >>> be showing them Seaside and Scriptaculous. Magritte is complex in the >>> same >>> way Glorp is complex, building all those metadata descriptions is complex >>> and error prone and takes way too much time to use in a demo, especially >>> a >>> time limited one. Whipping up something in raw Seaside would be much >>> faster >>> unless you've rigged up some code generators to write the mappings >>> automatically for you. >> >> I did try it both ways and building the editor by hand seemed to be more >> lines of code and I thought I'd go for something that might seem more >> familiar for the domain definition. Also, since I was building one component >> by hand trying the other as meta data seemed like reasonable variety. On the >> other hand, since I don't consider the whole experience a great success I >> certainly won't insist that I made the right choice. >> >>> Rails guys are accustomed to ActiveRecord and scaffolding which >>> bootstraps >>> them up to a running system very quickly using code generation and a >>> generate and modify philosophy (this is also how they learn Rails). >>> Gemstone might eliminate the need for ActiveRecord, but Magritte is not >>> at >>> all equivalent to scaffolding. Scaffolding is much easier to hack and >>> customize because it's not a framework, it's just a bunch of generated >>> form >>> template code. To compete against Rails in a time limited demo, you'll >>> need >>> something like a scaffolder, or a form builder you have a very deep >>> knowledge of so it can be highly customized on the fly. To sell newbs, >>> you >>> need the scaffolder, because scaffolding code is an excellent way to >>> teach >>> them how to write Seaside code, they don't need yet another framework >>> (Magritte) to learn. >> _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Randal L. Schwartz
Yes magritte is not compact enough.
This is not its goal. A DSL built on top could do the job. Stef On Jul 24, 2008, at 5:29 PM, Randal L. Schwartz wrote: >>>>>> "James" == James Robertson <[hidden email]> writes: > > James> Yes, Web Velocity would have been well suited for that. And > Randal has > James> a copy :) > > I was thinking it would be funny if I pulled out my laptop and started > from scratch with WV while the GS team was competing. :) > > The real problem seemed to be that there's a lot of code to type to > describe > the meta data (Magritte)... but once that code is typed, lots of > things are > available in very flexible ways. The other frameworks essentially > intermix > metadata and uses of that data, and would spend a lot longer to > *change* the > result once built. And we all know, the majority cost of software > is not > initial development, but *maintenance* in reaction to changing > minds^Wgoals > of the customer. > > For example, had the contest been to start with your already built > application > and then simply *add* the rating, the GS team would have been done > in 3 > minutes, while the other teams (I suspect) would have taken longer, > especially > to figure how how to migrate their persistent schemas. > > Also, James Foster - you gotta learn to use a code browser that has > ecompletion. I just started using one, and it's amazingly cool. It > would > have cut your typing time in half, likely. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 > 777 0095 > <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside > discussion > _______________________________________________ > 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 Ramon Leon-5
Agreed!
Stef On Jul 25, 2008, at 2:54 AM, Ramon Leon wrote: >> >> And if you were invited to a Ruby event and asked whether Seaside/ >> Magritte could support JavaScript, would you tell them that >> they were >> wrong for asking? >> >> James > > Nope, but I wouldn't be showing them Magritte either, that's a > mistake, I'd > be showing them Seaside and Scriptaculous. Magritte is complex in > the same > way Glorp is complex, building all those metadata descriptions is > complex > and error prone and takes way too much time to use in a demo, > especially a > time limited one. Whipping up something in raw Seaside would be > much faster > unless you've rigged up some code generators to write the mappings > automatically for you. > > Rails guys are accustomed to ActiveRecord and scaffolding which > bootstraps > them up to a running system very quickly using code generation and a > generate and modify philosophy (this is also how they learn Rails). > Gemstone might eliminate the need for ActiveRecord, but Magritte is > not at > all equivalent to scaffolding. Scaffolding is much easier to hack and > customize because it's not a framework, it's just a bunch of > generated form > template code. To compete against Rails in a time limited demo, > you'll need > something like a scaffolder, or a form builder you have a very deep > knowledge of so it can be highly customized on the fly. To sell > newbs, you > need the scaffolder, because scaffolding code is an excellent way to > teach > them how to write Seaside code, they don't need yet another framework > (Magritte) to learn. > > Ramon Leon > http://onsmalltalk.com > > _______________________________________________ > 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 |
Free forum by Nabble | Edit this page |