Just thought I would summarize my experience with Seaside (thanks Cedrick). I just started ~4 months ago, I'm relatively new to Seaside and Smalltalk and Web, I have prior experience with objects. I have not tried using Aida.
The Seaside community, both on this list and through private emails, has been astonishingly helpful (you know who you are :-) Ramon's blog was a big help, as were some assorted tutorials on the web. I did not make much use of the Pottsdam tutorial.
The forthcoming Seaside book should be a huge help (Hurry up, Stef, Lukas,... :-). Beginer docs (like Aida appears to have) were hard to find.
The html-in-code was easy with Seaside's Canvas, once I understood how the Brushes intervened.
Callbacks were trivial to program, apps with whole-page refresh very simple to do, though the use of #state never quite fit my needs.
Dealing with pure Smalltalk objects and callbacks on the server, with Seaside taking care of generating all string keys and mapping back to Smalltalk, a pure joy.
It took a while for me to get used to pulling in CSS and JS files into the image, changing CSS in method-body strings, and serving them out via FileLibrary accessors. It was also very frustrating figuring out that FireFox cached all this stuff unless you actually went into about:config and tweaked a parameter to turn it off.
Basic components were easy once I understood #children (which Seaside uses for several things like updating URLs and headers). I am curious if Aida requires something like #children, and what trade-offs it makes.
Ajax components were not easy, I went through a few depressing rounds of worrying about how much more I still had to understand to be productive. I was pushing Ajax a bit more than Seaside 2.8 was originally architected for. If you have the callback of one component changing and re-rendering the component-tree structure in a distant component, you better know what you are doing (and use Lukas #in:do: solution, see nabble archives). The way 2.8 does callback processing down the component tree in the presence of Ajax, depending on when the last complete #render:aComponent was called, is too complex for an app-programmer to have to understand; #in:do: seems to be a 2.8 fix, and this issue is scheduled to disappear in 2.9.
People have different opinions on a generic Seaside component library that fit together within a slightly higher-level UI framework. Personally I think it would be a huge asset, and would be delighted if Seaside (not "core", perhaps a separate package) made some opinionated decisions in this regard.
My 2 c,
Sophie
"itsme213" itsme213@hotmail.com wrote in message
...
... and all in all I am very happy that I stuck with it, I find Seaside + Scriptaculous to be a great framework for what I am trying to do.
Sophie
On Sun, Mar 30, 2008 at 10:55 AM, itsme213 itsme213@hotmail.com wrote:
Just thought I would summarize my experience with Seaside (thanks Cedrick). I just started ~4 months ago, I'm relatively new to Seaside and Smalltalk and Web, I have prior experience with objects. I have not tried using Aida.
I am envious of your rapid assent! Congratulations on your speedy knowledge acquisition! What kind of problems are you working on?
The Seaside community, both on this list and through private emails, has been astonishingly helpful (you know who you are :-) Ramon's blog was a big help, as were some assorted tutorials on the web. I did not make much use of the Pottsdam tutorial.
I have been wondering if Smalltalkers are so helpful because programming in Smalltalk is more like "teaching" than "programming" and if they are all basically a bunch of teachers that can't stand seeing someone have a hard time...?
The forthcoming Seaside book should be a huge help (Hurry up, Stef, Lukas,... :-). Beginer docs (like Aida appears to have) were hard to find.
Sometimes, there is just no substitute for a book...I am trying to contibute to the Aida documentation "as I learn it" from the newcomer point of view. Could such a documentation site be set up for Seaside? From what everyone has hinted at about your rapid success, you would probably be able to put some great examples there.
The html-in-code was easy with Seaside's Canvas, once I understood how the Brushes intervened.
This was where it got "hard" for me. I am, in a way, "so NOT interested" in "making it pretty." I want some basic business components, but I want them to be able to INTERACT in a complicated fashion due to the business problems I am working on.
Callbacks were trivial to program, apps with whole-page refresh very simple
to do, though the use of #state never quite fit my needs.
Dealing with pure Smalltalk objects and callbacks on the server, with Seaside taking care of generating all string keys and mapping back to Smalltalk, a pure joy.
Yes...I like not having to worry about mapping the state of the object to the view very much! Magic! However...it is, after all, exactly how it SHOULD be, isn't it...!
Can you not even realize that you are using Ajax in Seaside? Is it just a matter of creating an "Ajaxified" component? Or, do you have to "set up" your application to use those components? (Sorry...you mention Ajax below...)
It took a while for me to get used to pulling in CSS and JS files into the
image, changing CSS in method-body strings, and serving them out via FileLibrary accessors. It was also very frustrating figuring out that FireFox cached all this stuff unless you actually went into about:config and tweaked a parameter to turn it off.
I DID play with that to try to copy the Tab Strip example, and tried to modify some of the graphics and that sort of thing. The caching thing explains a lot. The "other" framwork has a WebStyle class where you put all your CSS, and you just tell it to reset when you make changes...that is pretty nice, and might be something you could do with your seemingly rapid understanding! They both need a built-in interface to browse to a graphic and suck it in if they are going to use method-body-strings, though! In both cases I had to figure out how to do that myself, which wasn't pretty! I mean, you have to learn how to compile a method!
Basic components were easy once I understood #children (which Seaside uses
for several things like updating URLs and headers). I am curious if Aida requires something like #children, and what trade-offs it makes.
I tried to work through the Magritte tutorial and ALWAYS ran into the "no children specified" error message or whatever. In Aida, (so far in my limited experience), there are no #children. You just add elements, or elements with elements (components) to other elements. I mean, you can access the "children" that have been created by these additions, but I don't think I quite understand #children. Url's are just automatically created, or specified with #preferedUrl to make a "pretty" Url.
Ajax components were not easy, I went through a few depressing rounds of worrying about how much more I still had to understand to be productive. I was pushing Ajax a bit more than Seaside 2.8 was originally architected for. If you have the callback of one component changing and re-rendering the component-tree structure in a distant component, you better know what you are doing (and use Lukas #in:do: solution, see nabble archives). The way 2.8 does callback processing down the component tree in the presence of Ajax, depending on when the last complete #render:aComponent was called, is too complex for an app-programmer to have to understand; #in:do: seems to be a 2.8 fix, and this issue is scheduled to disappear in 2.9.
The only thing I have tried to "push" in that way is for my applications to receive "signals" about external events, which I tried to implement with Announcements. Janko tells me this is Comet, and can be done, but I haven't been able to do it the way he explained it to me in Squeak, which seems to have more to to with the Process scheduling than Ajax.
This would be very helpful for me for things like Web Based tracking boards which don't constantly refresh themselves, but update when they recieve an Announcement.
People have different opinions on a generic Seaside component library that
fit together within a slightly higher-level UI framework. Personally I think it would be a huge asset, and would be delighted if Seaside (not "core", perhaps a separate package) made some opinionated decisions in this regard.
I stand firm in my belief in Standard Work! If you can automate something that you do all the time "by hand," that's a good thing. And, with Smalltalk, you should alway be able to "tweak" what the higer-level framework gives you, right?
Anyway, I would be happy to move the philosophical discussions around the available framework features off the list to avoid irritating anyone, if you like.
Maybe two beginners could manage to come up with some good ideas for something useful that way! (Maybe we should write our own higher-level UI framework. I have been thinking about it myself, and the gurus have create frameworks that would likely make it do-able for the less guru-ish...)
Thanks for all the input,
Rob
"Rob Rothwell" r.j.rothwell@gmail.com wrote in message
From what everyone has hinted at about your rapid success,
I am nowhere close to being an expert.
you would probably be able to put some great examples there.
I suspect that many of the ways that worked for me have more elegant solutions than what I found. Incremental improvement is good enough for me.
Can you not even realize that you are using Ajax in Seaside? Is it just a matter of creating an "Ajaxified" component? Or, do you have to "set up" your application to use those components? (Sorry...you mention Ajax below...)
Your domain objects should not change at all, and seaside components with well-factored #renderXYZ methods are easy to Ajaxify once you know some basics like #updater, #evaluator, #request (google Lukas' tutorial on Seaside/Web 2.0). If you will push Ajax it's worth understanding and using Lukas' #in:do.
They both need a built-in interface to browse to a graphic and suck it in if they are going to use method-body-strings, though!
Seaside has this somewhere in its config screens.
I tried to work through the Magritte tutorial and ALWAYS ran into the "no children specified" error message or whatever.
Magritte is a powerful and general meta-framework, and Pier uses Magritte. Perhaps take a look at Ramon's SSForm (available in his image on his blog site). Not quite as general and powerful as Magritte (which is a full reflective infra-structure), but might suit your need.
but I don't think I quite understand #children.
Nabble archives has a couple of posts by Lukas with explanations.
If you have the callback of one component changing and re-rendering the component-tree structure in a distant component
The only thing I have tried to "push" in that way is for my applications
I have not used server-side comet push, but did try Ajax refreshes where the callback of one component causes other components (on that same page) to change structure and re-render.
There is a Comet demo with Seaside on Squeaksource that looks quite simple and clean.
Maybe two beginners could manage to come up with some good ideas for something useful that way! (Maybe we should write our own higher-level UI framework.
If I feel close to competent for something like that anytime soon, perhaps :-)
Sophie
seaside@lists.squeakfoundation.org
-
itsme213 -
Rob Rothwell -
stephane ducasse