[Seaside] Brushes and state

Julian Fitzell jfitzell at gmail.com
Tue Jun 23 20:13:42 UTC 2009


Yes, I think so. Actually, what if you change to this method:
renderOn: aRenderer
  |html|
  html := WAHtmlCanvas
    context: aRenderer context
    callbacks: aRenderer context callbacks.
  self renderContentOn: html.

That may well be your problem. In 2.8, components are expected to own
callbacks and your object is not a component (in 2.9 this is not a problem).
But if you just use the existing callback registry created by the closest
component (as the above code does), I think it might be fine?

Julian

On Tue, Jun 23, 2009 at 12:27 PM, James Foster <Smalltalk at jgfoster.net>wrote:

> Any thoughts on the callback problem? Would that be fixed in 2.9?
> James
>
> On Jun 23, 2009, at 11:59 AM, Julian Fitzell wrote:
>
> 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.
>
> Julian
>
> 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
>>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090623/613f3e88/attachment-0001.htm


More information about the seaside mailing list