[Seaside] Brushes and state

Julian Fitzell jfitzell at gmail.com
Tue Jun 23 18:59:05 UTC 2009

Fair enough. I don't think there are any hard and fast rules. If you, as the
author, see your class more like a "special kind of div canvas tag" than as
something that has it's own protocol and happens to be currently implemented
by writing a div using a canvas, then so be it.
>From my point of view, composition feels better than subclassing here: if
you can easily generate the HTML you need with the existing tags, you
shouldn't need new ones. I don't see your class creating its own Canvas as
additional complexity, really (I realize it takes a little additional code
in 2.8) - it's no different than what
every component does. The RenderContext should carry on throughout (that's
why it's
there) but the API you want to use to render should be entirely up to you.

Anyway, thanks for humouring me in this little experiment. Hopefully others
have found it informative.


On Tue, Jun 23, 2009 at 9:22 AM, James Foster <Smalltalk at jgfoster.net>wrote:

> Julian,
> The #children problem is reported by Seaside in the usual manner with no
> extra explanation (see attached).
> The idea of passing a block to the was one that I thought of as well. I
> seem to recall that the X Window System had something analogous for
> initializing widgets (I can't lay my hands on any documentation, however).
> On the other hand, it seems to be adding complexity in that some things are
> set one way and some things another way. I'd almost prefer everything being
> done in the block:
> MyComponent>>#renderContentOn: html
> html render: (GoogleMap configure: [:map |
> map
> class: 'foo';
> style: 'bar';
> setCenter...;
> yourself.
> ].
> Of course, this has the disadvantage of forcing you to use the more complex
> style for everything.
> Without harping on the point too much, I'm still not feeling as
> uncomfortable as it seems I should with the Brush approach. One of the
> things mentioned as a characteristic of a Brush is that it can have things
> embedded in it (using #'with:'). There are exceptions already, including <br
> /> and <hr />, so this isn't really a firm rule. Also, a GoogleMap makes
> sense only on an WAHtmlCanvas. While it can create its own Canvas, that
> seems a bit of an additional complexity. I guess I'm still
> seeing HorizontalRule, Button, TextInput, ListBox, and GoogleMap as being on
> a continuum of simple to complex but otherwise not substantively different
> in the way they are created and used. For some, embedding other tags makes
> sense; for others it does not. Most can display user-defined data and return
> new values. Most have events that can trigger asynchronous callbacks. All
> are represented by HTML Tags. Some share tags but are distinguished only by
> the class (input button). With the GoogleMap, I could even imagine embedding
> other content that would show if JavaScript were disabled in the browser.
> In any case, it seems like several options are available. Maybe if new
> Painters were more familiar, that approach wouldn't seem so different.
> (Okay, having typed that last sentence I see that it isn't very profound!)
> James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090623/697adfb9/attachment.htm

More information about the seaside mailing list