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.<div>
<br></div><div>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.</div>
<div><br></div><div>Anyway, thanks for humouring me in this little experiment. Hopefully others have found it informative.</div><div><br></div><div>Julian<br><br><div class="gmail_quote">On Tue, Jun 23, 2009 at 9:22 AM, James Foster <span dir="ltr"><<a href="mailto:Smalltalk@jgfoster.net">Smalltalk@jgfoster.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div>Julian,</div><div><br></div><div>The #children problem is reported by Seaside in the usual manner with no extra explanation (see attached).</div>
<div><br></div><div>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:</div>
<div><br></div><div>MyComponent>>#renderContentOn: html</div><div><span style="white-space:pre"> </span>html render: (GoogleMap configure: [:map | </div><div><span style="white-space:pre"> </span>map</div><div><span style="white-space:pre"> </span>class: 'foo';</div>
<div><span style="white-space:pre"> </span>style: 'bar';</div><div><span style="white-space:pre"> </span>setCenter...;</div><div><span style="white-space:pre"> </span>yourself.</div><div><span style="white-space:pre"> </span>].</div>
<div><br></div><div>Of course, this has the disadvantage of forcing you to use the more complex style for everything. </div><div><br></div><div>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.</div>
<div><br></div><div>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!)</div>
<div><br></div><font color="#888888"><div>James</div></font></div></blockquote></div></div>