[Seaside] Brushes and state

[James Foster]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090623/8d021ce4/attachment.htm