<div class="gmail_quote">On Sat, Jun 20, 2009 at 3:22 PM, Colin Putney <span dir="ltr"><<a href="mailto:cputney@wiresong.ca">cputney@wiresong.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 19-Jun-09, at 12:20 PM, Julian Fitzell wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
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.<div class="im">
</div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
I think the problem here is that it violates the intent of the design.<br>
<br>
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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.</blockquote><div><br></div><div>
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.</div>
<div><br></div><div>I'm curious to see whether James' results from trying to implement GoogleMap as a painter-like object in 2.8 confirm this.</div><div><br></div><div>Julian</div></div>