[Seaside] Brushes and state

[Mariano Montone]

Thanks Julian. I think a component will be ok.

Mariano

On Thu, Jun 18, 2009 at 1:22 PM, Julian Fitzell <jfitzell at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/462692f5/attachment.htm