[Seaside] Brushes and state
marianomontone at gmail.com
Thu Jun 18 21:58:06 UTC 2009
Thanks Julian. I think a component will be ok.
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. :)
> On Thu, Jun 18, 2009 at 5:51 AM, Mariano Montone <marianomontone at gmail.com
> > wrote:
>> I'm implementing an API for rendering Google Maps. I've decided
>> 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.
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
> seaside mailing list
> seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside