[Seaside] Brushes and state

[James Foster]

Julian,

I think the only think I'm equipped to give even a weak opinion on is  
that as I was doing this some months ago I found a Brush to be more  
natural to use (as a client) than a Canvas. As to the relative merits  
of Painter and Renderer, I'm just not sufficiently informed to venture  
an educated opinion (though that isn't usually an impediment ;-).

I like your point that a Brush can be embedded in another Brush and  
this is a feature that the GoogleMap does not need. Given that sending  
#with: to a GoogleMap does not make sense, I'll agree that making it a  
Brush is a bit awkward. Also, there is a sense in which subclassing  
from WADivTag comes back to the question of delegation vs.  
inheritance, and in principal I'd prefer delegation.

In an effort to contribute more intelligently to this discussion, I'd  
like to try refactoring my library using a Painter. I'll fire up a  
Seaside 2.9 environment and look at WAPainter with an eye toward what  
would be required to refactor my GoogleMap in a Seaside 2.8 environment.

James

On Jun 19, 2009, at 12:20 PM, Julian Fitzell wrote:

> On Fri, Jun 19, 2009 at 10:50 AM, James Foster  
> <Smalltalk at jgfoster.net> wrote:
> Julian,
>
> As you were going through this my thought was eventually expressed  
> when you said that the painter approach "works essentially the same  
> as the brush" approach. And Yes, my updateRoot: code was simply an  
> extension to WAComponent that adds some JavaScript. Switching it to  
> a class-side method on GoogleMaps as you describe would be  
> equivalent and perhaps more obvious and less intrusive.
>
> The part I'm not yet following or seeing much value in is the idea  
> that using a different renderer would be desirable. I don't see much  
> point of rendering a GoogleMap on anything other than an HTML  
> canvas. Or are you envisioning two renderers (HTML for the GoogleMap  
> thing and something else for the rest)? At the moment, my  
> understanding of the alternate renderers is so shallow that I don't  
> see the use/value. For my purposes, at least, I'll probably leave my  
> implementation as a Brush subclass since it seems to work for all  
> use cases I understand. Which is not to say that I mind the  
> discussion!
>
> James,
>
> The discussion is clarifying for me as well so let's carry on... :)
>
> First, I do think your design would be improved slightly by putting  
> that method on the class side of GoogleMap.
>
> The idea of having different Renderers is that, for example,  
> somebody might eventually decide they'd really like to have  
> templates in Seaside and that would probably be implemented as a  
> different Renderer. Or maybe they want to embed a google map in a  
> Component that is using the RSS Renderer (actually, that Renderer  
> still uses Brushes, so it may not be the best example). As I said,  
> this is relatively theoretical at the moment given the lack of other  
> Renderers but I'm interested in it from the architectural angle.
>
> I believe (and this is where I may be wrong) that an implementation  
> using Brushes is (slightly) less flexible and, while there are  
> things that would be easier using Brushes, I don't see that this  
> problem does any of those things.
>
> Or to look at it another way, just as you say that GoogleMap doesn't  
> need to *be* a Component but can be rather *used by* a Component, I  
> don't think it needs to *be* a Brush but can instead *use* a Brush;  
> there's nothing you need to output to the Document that can't easily  
> be done with the existing Brushes.
>
> So you might end up with
>
> MyComponent
>   (uses)
> any Renderer
>   (to render a)
> GoogleMap (a Painter)
>   (which uses its)
> HtmlCanvas (a Renderer)
>   (to get a)
> DivTag (a Brush)
>   (which writes to)
> HtmlDocument (a Document)
>   (which writes to)
> Stream
>
> When I say it "works essentially the same as the brush", what I mean  
> is, the Painter implementation is equally convenient to use and no  
> harder to implement but provides added flexibility. It also requires  
> no class method extensions and means you can leverage WAScriptTag  
> instead of duplicating stuff to make sure the CDATA is added and so  
> on. Since I can't (yet) see an advantage to the Brush  
> implementation, my suggestion is that the Painter implementation is  
> "more correct" architecturally.
>
> I still think "uses a Brush" (actually two) is a clearer  
> relationship for this than "is a Brush" even in 2.8, but without  
> Painter there's really no added benefit (though you could easily  
> duplicate the very limited amount of functionality Painter has in  
> its #renderOn: method and you'd be in the same shape as 2.9).
>
> So the architectural question for me comes down to (sorry for the  
> long message), is there an additional benefit to doing it as a Brush  
> over a Painter that I'm missing?
>
> Julian
> _______________________________________________
> 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/20090619/faf8c93a/attachment.htm