[Seaside] Another Seasider newbie's experience

[Rob Rothwell]

On Sun, Mar 30, 2008 at 10:55 AM, itsme213 <itsme213 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20080330/f516cce7/attachment-0001.htm