About Seaside 3.0
Locked
123
123
 
|
Hello guys
I was driving under the rain during 4 hours and my brain was wandering... I got to think on what would be the most important point for Seaside 3.0 Here is my thoughts: may be I'm totally wrong but I watched some of the Ror stuff and we have to learn from them. - Better and more ready to use components. - Straightforward and dead simple to use for dummies like me persistency. I think that as a community we should pay attention that this is not because we will be technical superior we will survive (even if 2.8 and 2.9 cleans are cool - lukas and philippe know that I think that they did an EXCELLENT job). Now I'm thinking for the next step that could really blow away the rest of people not thinking that Seaside is coooool. Stef _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I was recently using turbogears, for python, and I really liked the template thing that it has, maybe we should try yo build something like that for seaside?
On Sat, Jul 12, 2008 at 11:10 AM, stephane ducasse <[hidden email]> wrote: Hello guys -- David Zmick /dz0004455\ http://dz0004455.googlepages.com http://dz0004455.blogspot.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
>>>>> "David" == David Zmick <[hidden email]> writes:
David> I was recently using turbogears, for python, and I really liked the David> template thing that it has, maybe we should try yo build something like David> that for seaside? If we do that, it should be OMeta based, so that every end user can tweak and extend it easily. -- 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 David Zmick
On 12-Jul-08, at 9:12 AM, David Zmick wrote: > I was recently using turbogears, for python, and I really liked the > template thing that it has, maybe we should try yo build something > like that for seaside? I'm not familiar with turbogears, but I think that reintroducing templates would be a step backwards. Seaside 1 had quite a nice template system, and I wrote another one for Seaside 2 that resembled Lisp macros. But both of those systems were abandoned because programatic HTML generation is actually better than templates. For smaller apps, it seems like a wash: you're just writing HTML with Smalltalk syntax, and there this layer of indirection that you have to understand so that you can produce the HTML you have in mind. But as the size of an app grows, programmatic HTML generation becomes more and more valuable. You can factor it into rendering methods that create common-ly used bits of markup. You bring all the power of the Smalltalk IDE to bear on it - even simple things like "senders" and "implementers" is really valuable. Colin _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by David Zmick
>
> I was recently using turbogears, for python, and I really > liked the template thing that it has, maybe we should try yo > build something like that for seaside? Are you talking about templates for the HTML? I hope not, the lack of HTML templates is one of the primary features of Seaside, not an omission. Or are you talking about some kind of starter templates for creating a skeleton of an application to get you going? If the latter, what does it create that you'd like to see in Seaside? Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
Stephane - I agree with your two points. Note that Gemstone and Cincom seem to agree on the persistence issue (but are taking radically different approaches to addressing in).
I'd like to see some discussion about making it easy to deploy Seaside on the Amazon cloud. Make it easy to build sexy apps (better components), easy to use and scalable persistence (AWS) and we have a really great story. The Cog VM would be icing on the cake (it would reduce the $ to deploy). -david On Sat, Jul 12, 2008 at 11:10 AM, stephane ducasse <[hidden email]> wrote: Hello guys _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
2008/7/12 stephane ducasse <[hidden email]>:
> Hello guys > > I was driving under the rain during 4 hours and my brain was wandering... > I got to think on what would be the most important point for Seaside 3.0 > Here is my thoughts: may be I'm totally wrong but I watched some of the Ror > stuff and > we have to learn from them. > > - Better and more ready to use components. Should not be part of Seaside, should be separate project. > - Straightforward and dead simple to use for dummies like me > persistency. Should be separate project as well. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> > - Better and more ready to use components.
> > Should not be part of Seaside, should be separate project. +1, there's no such thing as a ready to use UI component, one size does not fit all and UI components don't belong in Seaside. I'd even like to see #request: and #inform: removed because it plants such ideas in peoples heads. Seaside can be used to build many UI frameworks, like wrapping MooTools, YUI, XUL, or the myriad of other current and future UI components. There's no reason you shouldn't have a choice between any of the various competing component libraries which should all be separate projects. > > > - Straightforward and dead simple to use for dummies like me > > persistency. > > Should be separate project as well. > > Cheers > Philippe Also +1, persistence is not a web framework's job, it's a persistence framework's job and you should be able to use any one of the various competing persistence frameworks with Seaside. Ruby on Rails is not technically a web framework, it's a collection of frameworks in an application stack; that it's called a framework is more marketing than truth. The web framework within Rails is called ActionPack, that's what Seaside is. ActiveRecord is the persistence framework used by the Rails stack, for Seaside that's Gemstone, Glorp, GOODS, Magma, OmniBase, Roe or the Image itself depending on what you need. If there's anything to learn from Rails, it's that the stack can benefit from being very well integrated from an outside point of view so that it appears all the parts were made to fit together. That doesn't mean we need to dump everything into Seaside, and it's too late for that anyway. Rails came out of the gate with just ActiveRecord and everyone uses it, but you won't get the Seaside community to do that, we already have more than one persistence option and you aren't going to be able to pick any one bless it as *the* one. There may be things Seaside can learn from Rails, but it shouldn't copy Rails. Convention over configuration, tight integration, simple to use, easy to setup, all good things; on the other hand html templates, url hacking with regex and manual marshaling of state, integrated code generators/scaffolding, focus on statelessness, all IMHO, bad things and a direction I'd hate to see Seaside go. Even the Rails guys spent a lot of time on 2.0 trying to push things out of the core and into plugins or separate gems because they realized it was a mistake including them in the core. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Ramon, I coulden't agree more.
To justify a major version jump from 2.x to 3.0 we need something radically better. Seaside 2.0 was a complete rewrite over Seaside 0.98. The manpower (and interest?) to start such an endavour seems to be missing currently. Cheers, Lukas On 7/12/08, Ramon Leon <[hidden email]> wrote: >> > - Better and more ready to use components. >> >> Should not be part of Seaside, should be separate project. > > +1, there's no such thing as a ready to use UI component, one size does not > fit all and UI components don't belong in Seaside. I'd even like to see > #request: and #inform: removed because it plants such ideas in peoples > heads. Seaside can be used to build many UI frameworks, like wrapping > MooTools, YUI, XUL, or the myriad of other current and future UI components. > There's no reason you shouldn't have a choice between any of the various > competing component libraries which should all be separate projects. > >> >> > - Straightforward and dead simple to use for dummies like me >> > persistency. >> >> Should be separate project as well. >> >> Cheers >> Philippe > > Also +1, persistence is not a web framework's job, it's a persistence > framework's job and you should be able to use any one of the various > competing persistence frameworks with Seaside. Ruby on Rails is not > technically a web framework, it's a collection of frameworks in an > application stack; that it's called a framework is more marketing than > truth. The web framework within Rails is called ActionPack, that's what > Seaside is. ActiveRecord is the persistence framework used by the Rails > stack, for Seaside that's Gemstone, Glorp, GOODS, Magma, OmniBase, Roe or > the Image itself depending on what you need. > > If there's anything to learn from Rails, it's that the stack can benefit > from being very well integrated from an outside point of view so that it > appears all the parts were made to fit together. That doesn't mean we need > to dump everything into Seaside, and it's too late for that anyway. Rails > came out of the gate with just ActiveRecord and everyone uses it, but you > won't get the Seaside community to do that, we already have more than one > persistence option and you aren't going to be able to pick any one bless it > as *the* one. > > There may be things Seaside can learn from Rails, but it shouldn't copy > Rails. Convention over configuration, tight integration, simple to use, > easy to setup, all good things; on the other hand html templates, url > hacking with regex and manual marshaling of state, integrated code > generators/scaffolding, focus on statelessness, all IMHO, bad things and a > direction I'd hate to see Seaside go. Even the Rails guys spent a lot of > time on 2.0 trying to push things out of the core and into plugins or > separate gems because they realized it was a mistake including them in the > core. > > Ramon Leon > http://onsmalltalk.com > > > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
>
> Ramon, I couldn't agree more. > > To justify a major version jump from 2.x to 3.0 we need something > radically better. Seaside 2.0 was a complete rewrite over Seaside > 0.98. The manpower (and interest?) to start such an endavour seems to > be missing currently. > > Cheers, > Lukas With 2.9 not even out of the gate yet and 2.8 still the stable release, maybe it's a bit premature to be discussing a 3.0. As long as the core is lean, mean, and clean, and there's nothing just jumping out of the community that looks like it should be harvested for the core, is there really a need push for another version? With all of the other Smalltalk's scrambling to support Seaside and bring people from their communities in, and the various cross platform issues that are likely to keep creeping up, maybe now is better a time to sit back and develop some stability and let the community grow a bit without making every chase Squeak trying to keep up with the latest version. Here's a few ideas of existing things we could improve without needing a major release... * Things like Dale exploring reusing existing callback state so every hit doesn't have to generate new state in the session. * Maybe spend some time exploring real world issues like how to run a single site that flips back and forth between secure and non secure pages dynamically and generating the anchors correctly (I hacked up my own versions of secureCallback: and unsecuredCallback: to do this on ReserveTravel) because setting the server port and server protocol globally on the application itself seems wrong, but maybe I'm missing something. * How about some fancier methods built in for how sessions expire so a rouge bot can't just come along and chew up all your ram till your image dies. Avi had a nice idea a while back on a sliding expiration time based on how many times the session was, simple but likely very effective against stupid bots that hit you 10000 times with each hit starting a new session. * How about some attention into how sessions are implemented with dynamic variables that you lose access to when you fork a block and try to do anything asynchronously. I'm not the only one that's been bitten by this. * Is there a possibility of using ImageSegments to partition out the state of a Seaside node so upgrades can be rolled out to load balanced farms by having the running node save and quit and immediately start up a new version to replace it so users only notice a momentary pause but not have their sessions blown away? It's one thing to hot upgrade a site running in a single image with VNC or the web interface, but if you're load balancing a whole slew of nodes that's just not going to work. It's much easier to copy out a new image and restart all the nodes. * What about some resources for helping people running Seaside sites with Apache, really good example Apache configs with load balancing and Dabble style dynamic launching and shutting down of images to suite the demands of the current load. Seaside deployment is not trivial and everyone stumbles over these issues time and time again. Anyway, just a few things to think about, but my point is there's plenty of things to do now, without needing to think of some ground breaking idea that would justify a new major version. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I was talking about html templates, because, they are eisier to build, and read, with css, than the seaside concepts, I think.
On Sat, Jul 12, 2008 at 7:48 PM, Ramon Leon <[hidden email]> wrote: > -- David Zmick /dz0004455\ http://dz0004455.googlepages.com http://dz0004455.blogspot.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
>
> I was talking about html templates, because, they are easier > to build, and read, with css, than the seaside concepts, I think. Then I agree with Colin, templates are a step backwards, been there, done that, glad we've moved beyond it. Templates were never a good idea because they force you to mix in some kind of code in with them to do anything at all interesting, even a simple grid full of data requires at a minimum a loop construct and html is a horrible syntax for a programming language. If Smalltalk code is capable of representing the exact same data structures as html is, then we don't need html, and the tools for dealing with code are vastly superior to the tools for dealing with html. Seaside's throwing out templates is one of its best and most bold features. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by David Zmick
If seaside is truly capable of being integrated with external libraries (and I cast no doubt on this), then it should be possible for the enthusiasts for templates to resurrect the template system, or write their own.
On 7/12/08, Ramon Leon <[hidden email]> wrote: > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Ramon Leon-5
> > * How about some fancier methods built in for how sessions expire so a > rouge bot can't just come along and chew up all your ram till your image > dies. Avi had a nice idea a while back on a sliding expiration time based > on how many times the session was, simple but likely very effective against > stupid bots that hit you 10000 times with each hit starting a new session. > I've been bit by this. This is a biggie. Nevin _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
My last 3 projects came to me with already populated mysql databases
as starting points. So I chose RoR because bending ActiveRecord onto mysql is dead easy. Bonus, tools like activescaffold automated creation of CRUD gui's to the extent that I was able to get out of writing a LOT of admin code that I would have to write in seaside. It is instant CRUD with optional customization. Also, if you want to break into the commerce game (and mostly, I'm doing small business commerce work these days), then porting activemerchant would be a brilliant idea. Once again, I find lots of people wanting a site suited for building a little community around a couple of products and having a simple little web shop. IOW, consider the website requirements for a shareware author. He needs user management (signup, password recovery, access control), payment processing, forums, a blog, and some static content. For this stuff, people turn to things like Drupal, oscommerce, ubercart, zencart, phpbb, mephisto, beast, and so forth. Lots of pieces, but still nothing quite ready to go - lots of stitching is still required. Just some food for thought based on my clients' requirements over the last six months. -Todd Blanchard On Jul 12, 2008, at 9:10 AM, stephane ducasse wrote: > Hello guys > > I was driving under the rain during 4 hours and my brain was > wandering... > I got to think on what would be the most important point for Seaside > 3.0 > Here is my thoughts: may be I'm totally wrong but I watched some of > the Ror stuff and > we have to learn from them. > > - Better and more ready to use components. > - Straightforward and dead simple to use for dummies like me > persistency. > > I think that as a community we should pay attention that this is not > because > we will be technical superior we will survive (even if 2.8 and 2.9 > cleans are cool - lukas > and philippe know that I think that they did an EXCELLENT job). > > Now I'm thinking for the next step that could really blow away the > rest of people > not thinking that Seaside is coooool. > > Stef > _______________________________________________ > 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 Nevin Pratt
2008/7/13 Nevin Pratt <[hidden email]>:
> >> * How about some fancier methods built in for how sessions expire so a >> rouge bot can't just come along and chew up all your ram till your image >> dies. Avi had a nice idea a while back on a sliding expiration time based >> on how many times the session was, simple but likely very effective >> against >> stupid bots that hit you 10000 times with each hit starting a new session. >> > > I've been bit by this. This is a biggie. Well then, there you go: http://code.google.com/p/seaside/issues/detail?id=96 Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Ramon Leon-5
Please create feature requests on the Google bug tracker for your wishes.
On 7/13/08, Ramon Leon <[hidden email]> wrote: >> >> Ramon, I couldn't agree more. >> >> To justify a major version jump from 2.x to 3.0 we need something >> radically better. Seaside 2.0 was a complete rewrite over Seaside >> 0.98. The manpower (and interest?) to start such an endavour seems to >> be missing currently. >> >> Cheers, >> Lukas > > > With 2.9 not even out of the gate yet and 2.8 still the stable release, > maybe it's a bit premature to be discussing a 3.0. As long as the core is > lean, mean, and clean, and there's nothing just jumping out of the community > that looks like it should be harvested for the core, is there really a need > push for another version? > > With all of the other Smalltalk's scrambling to support Seaside and bring > people from their communities in, and the various cross platform issues that > are likely to keep creeping up, maybe now is better a time to sit back and > develop some stability and let the community grow a bit without making every > chase Squeak trying to keep up with the latest version. > > Here's a few ideas of existing things we could improve without needing a > major release... > > * Things like Dale exploring reusing existing callback state so every hit > doesn't have to generate new state in the session. > * Maybe spend some time exploring real world issues like how to run a > single site that flips back and forth between secure and non secure pages > dynamically and generating the anchors correctly (I hacked up my own > versions of secureCallback: and unsecuredCallback: to do this on > ReserveTravel) because setting the server port and server protocol globally > on the application itself seems wrong, but maybe I'm missing something. > * How about some fancier methods built in for how sessions expire so a > rouge bot can't just come along and chew up all your ram till your image > dies. Avi had a nice idea a while back on a sliding expiration time based > on how many times the session was, simple but likely very effective against > stupid bots that hit you 10000 times with each hit starting a new session. > * How about some attention into how sessions are implemented with dynamic > variables that you lose access to when you fork a block and try to do > anything asynchronously. I'm not the only one that's been bitten by this. > * Is there a possibility of using ImageSegments to partition out the state > of a Seaside node so upgrades can be rolled out to load balanced farms by > having the running node save and quit and immediately start up a new version > to replace it so users only notice a momentary pause but not have their > sessions blown away? It's one thing to hot upgrade a site running in a > single image with VNC or the web interface, but if you're load balancing a > whole slew of nodes that's just not going to work. It's much easier to copy > out a new image and restart all the nodes. > * What about some resources for helping people running Seaside sites with > Apache, really good example Apache configs with load balancing and Dabble > style dynamic launching and shutting down of images to suite the demands of > the current load. Seaside deployment is not trivial and everyone stumbles > over these issues time and time again. > > Anyway, just a few things to think about, but my point is there's plenty of > things to do now, without needing to think of some ground breaking idea that > would justify a new major version. > > Ramon Leon > http://onsmalltalk.com > > > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
> > - Better and more ready to use components.
> > Should not be part of Seaside, should be separate project. > I second the notion for having more components and for having it as a separate project. How about those names: Smalltalk Server Faces? Smalltalk Wealthy Faces? -- Claus Kick "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie." "If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiotism and insanity." _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Marcin Tustin
Yes, I think this is the key point. I think there's a general
consensus among most Seaside developers at this point that we prefer not having a template engine. I hesitate to make a blanket statement such as "templates are bad", though, and as Colin said various template systems have existed. When we started writing Seaside 2 (and again during the first few successive minor releases), we concentrated on ensuring a layered architecture. The goal was to allow people to use many of the layers independently of each other and for alternatives to some of the layers to develop. In the end, this hasn't really been exercised much but I'm sure the boundaries are still defined enough for an interested party to easily develop a template system (or resurrect Nori). If that layering has become less defined somewhere and prevents doing so, I'm sure there would be support for correcting that. Julian On Sun, Jul 13, 2008 at 10:47 AM, Marcin Tustin <[hidden email]> wrote: > If seaside is truly capable of being integrated with external libraries (and > I cast no doubt on this), then it should be possible for the enthusiasts for > templates to resurrect the template system, or write their own. > > On 7/12/08, Ramon Leon <[hidden email]> wrote: >> >> > >> > I was talking about html templates, because, they are easier >> >> > to build, and read, with css, than the seaside concepts, I think. >> >> >> Then I agree with Colin, templates are a step backwards, been there, done >> that, glad we've moved beyond it. Templates were never a good idea >> because >> they force you to mix in some kind of code in with them to do anything at >> all interesting, even a simple grid full of data requires at a minimum a >> loop construct and html is a horrible syntax for a programming >> language. If >> Smalltalk code is capable of representing the exact same data structures >> as >> html is, then we don't need html, and the tools for dealing with code are >> vastly superior to the tools for dealing with html. Seaside's throwing >> out >> templates is one of its best and most bold features. >> >> >> 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 > > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Ramon Leon-5
On Sun, Jul 13, 2008 at 8:48 AM, Ramon Leon <[hidden email]> wrote:
>> >> Ramon, I couldn't agree more. >> >> To justify a major version jump from 2.x to 3.0 we need something >> radically better. Seaside 2.0 was a complete rewrite over Seaside >> 0.98. The manpower (and interest?) to start such an endavour seems to >> be missing currently. > > With 2.9 not even out of the gate yet and 2.8 still the stable release, > maybe it's a bit premature to be discussing a 3.0. As long as the core is > lean, mean, and clean, and there's nothing just jumping out of the community > that looks like it should be harvested for the core, is there really a need > push for another version? > > With all of the other Smalltalk's scrambling to support Seaside and bring > people from their communities in, and the various cross platform issues that > are likely to keep creeping up, maybe now is better a time to sit back and > develop some stability and let the community grow a bit without making every > chase Squeak trying to keep up with the latest version. Also, the next version after 2.9 can always be 2.10. There's nothing saying there *has* to be a 3.0 at this point. I agree it could be a good time to focus on softer issues such as documentation, deployment, scaling, porting, and so on. Standard "patterns" may be more useful than "components". Julian _______________________________________________ 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 |