[Seaside] Brushes and state

[Julian Fitzell]

That should provide a good comparison.
Looking at the 2.9 code now I realize it may be hard for you to simply lift
the code because of the refactoring in the way walking the component tree
happens.

As a starting point for 2.8, try making GoogleMap subclass Object and
implement something like:

renderOn: aRenderer
  |html|
  html := WAHtmlCanvas
    context: aRenderer context
    callbacks: (aRenderer context callbacksFor: self).
  self renderContentOn: html.

I think you should then be able to implement #renderContentOn: to output
your content and allow a GoogleMap to be passed to the #render: method.

That code is untested, just typed into gmail, but it should be something
like that. :)

Julian

On Fri, Jun 19, 2009 at 4:43 PM, James Foster <Smalltalk at jgfoster.net>wrote:

> 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
>
>
>
> _______________________________________________
> 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/efd1d34f/attachment-0001.htm