Another Seasider newbie's experience

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Another Seasider newbie's experience

Sophie424
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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Another Seasider newbie's experience

Sophie424
"itsme213" <[hidden email]> 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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Another Seasider newbie's experience

stephane ducasse
In reply to this post by Sophie424
>
>
> The forthcoming Seaside book should be a huge help (Hurry up, Stef,
> Lukas,... :-).

:)
yes kick us. This is a painful process to write in another language  
without a debugger :)
especially when you have to do 3 billion other things.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Another Seasider newbie's experience

Rob Rothwell
In reply to this post by Sophie424
On Sun, Mar 30, 2008 at 10:55 AM, itsme213 <[hidden email]> 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

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Another Seasider newbie's experience

Sophie424
"Rob Rothwell" <[hidden email]> 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 mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside