[Seaside] Brushes and state

[Julian Fitzell]

Hi Mariano,

Off the top of my head, if I were implementing a google maps package, I
would do it as a component or a painter (see below). Brushes certainly
aren't intended to be kept around so if you have state to persist between
requests that's not the way to go.

There are people who like implementing everything as brushes but the main
functionality of brushes is that they can be selected in arbitrary orders to
nest content within each other, e.g.:

html div: [ html span: [ html paragraph: 'foo' ] ].

Unless you plan to do be able to do:

html div: [ html googleMap: [ html paragraph: 'foo' ] ]

(i.e. unless the thing you are creating allows content to be put inside it)
I don't think there's much advantage in making your own brush. (The other
reason to consider using brushes of course is that they have more direct
access to the document).

Even if you don't need the benefits of components (see
http://blog.fitzell.ca/2009/05/when-to-use-seaside-component.html ), you can
just create a renderable object by implementing #renderOn: and do:

html render: (GoogleMaps new configSomeStuff; yourself)

This process is made much clearer in 2.9 where you can subclass WAPainter,
implement #rendererClass to control what kind of renderer you get passed
(you might possibly implement the google maps thing *using* one or more
custom brushes and have your own renderer for them), and implement
#renderContentOn: as you would for a component.

Hopefully that makes things clearer and not muddier. :)

Julian

On Thu, Jun 18, 2009 at 5:51 AM, Mariano Montone
<marianomontone at gmail.com>wrote:

> Hello!,
>            I'm implementing an API for rendering Google Maps. I've decided
> to implement it as a brush. That's because I'm just generating javascript
> code. But now I have a problem: when adding support for callbacks, I need to
> hold some state; for example, the map the callback refers to. But I think
> brushes are not meant to hold state, that is something left for the
> components mechanism, isn't it? So I would like to know what would be the
> correct way of implementing it in the framework. Should I implement maps as
> components, or should I add state to my brushes; I may hold a state in the
> callback block too, but I don't think that's good.
>
> Thanks!
>
> Mariano
>
>
>
> _______________________________________________
> 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/20090618/c9e15b15/attachment.htm