[Seaside] Brushes and state

[Julian Fitzell]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090619/e9faceaa/attachment-0001.htm