[Seaside] Brushes and state

[Julian Fitzell]

On Sat, Jun 20, 2009 at 3:22 PM, Colin Putney <cputney at wiresong.ca> wrote:

>
> On 19-Jun-09, at 12:20 PM, Julian Fitzell wrote:
>
>  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.
>>
>
> Well, too theoretical. I'm working integrating my Altitude experiment back
> into Seaside 2.9. It makes changes to the rendering of links and forms, so
> I'm using an alternate Renderer to allow it to exist side-by-side with the
> normal behavior. Creating alternate renderers isn't a very common need, but
> it's really handy when you need to do something out of the ordinary. Without
> adding special support, I wouldn't be able to use James maps implementation
> with Atitude.
>

Agreed. Nobody much has taken advantage of custom Renderers so far but I
think that's partly because the architecture hasn't been as clear as it
could have been in the last few recently. It's much improved now (I'll get
some diagrams out before we go final) and I suspect people will find more
uses for it as they become more familiar with the full architecture.


>  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.
>>
>
> I think the problem here is that it violates the intent of the design.
>
> WAHtmlCanvas provides an abstraction for generating HTML. It does provide a
> very few higher level abstractions, such as callbacks, but generally it
> operates at the level of tags and attributes. Rendering a higher-level
> abstraction in terms of HTML tags is not the roll of a brush, it's the roll
> of a component. Now, if you don't need to retain state between HTTP
> requests, you don't need a full component; a simple painter will do.
>

In fact the Canvas doesn't even really provide callbacks. Callbacks are in
the Core package and could be used without the Canvas package even being
loaded. The CallbackRegistry is held by the RenderContext, with which every
Renderer (including Canvases) are initialized. Renderer simply exposes the
callback functionality of its context to its users.

I think implementing a new kind of brush should be a fairly rare thing, and
> reserved for those occasions where you need to generate markup that the
> regular WAHtmlCanvas can't produce.


That's my contention too. In particular, as I said to James, Brushes are
intended to be "stacked" so if it doesn't make sense for someone to stack
another Brush on top of yours, that's a warning sign. Also, TagBrushes are
pretty much intended to be directly mapping to X(HT)ML tags so if yours
isn't you're probably fighting against something there. Finally, if you find
your Brush either duplicating code from another Brush or actually trying to
*use* another Brush I'd consider that a warning sign too.

I'm curious to see whether James' results from trying to implement GoogleMap
as a painter-like object in 2.8 confirm this.

Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090620/5e3880ba/attachment.htm