[Seaside] Checkbox attributes

[Avi Bryant]

On Jun 24, 2004, at 7:40 AM, C. David Shaffer wrote:

> The use of hidden fields around checkboxes in 
> WAHtmlRendered>>checkboxWithValue:callback:confuses attribute 
> settings.  That is, if you set attributes then invoke that method, 
> your attributes are placed on a hidden field and not the checkbox 
> itself.  I can't imagine a situation in which that is what you wanted. 
>  I propose changing that method to something like:

<snip>

Your solution is fine, and I agree that it's needed.  I'll merge it 
ASAP.

This is probably a good time to mention that I've been working on a 
replacement for HtmlRenderer that wouldn't have had this problem, and 
which generally gets rid of a lot of the ugly bits of the current 
render protocol.  A preview will be included in the next release, and 
I'll probably try to make it a fully functional replacement for 
HtmlRenderer by 2.6 (and the default by 2.7?).

The metaphor I'm using for it is of a canvas and brushes.  So:
- you are given a canvas object, much as you are now given a Renderer, 
in #renderContentOn:
- you obtain brushes from the canvas through unary messages.  For 
example, sending the canvas #anchor would return an AnchorBrush.
- you then configure the brushes (er, dip them in paint?).  For 
example, you might configure your AnchorBrush by setting its #name:, or 
its #href:, or alternatively giving it an #action:.
- once the brush is configured, you get to paint with it.  All brushes 
implement #with: which takes a block.  Anything inside that block is 
done "using" the configured brush.  Here's where the metaphor breaks 
down a little, however, because brushes are nested: what you probably 
do inside that block is obtain more brushes from the canvas, and use 
them, etc.  "Using" an AnchorBrush means printing an open <a>, 
executing the block, then printing a close </a>.
- brushes are disposable; once the #with: block is over, you can't use 
them again, but have to get a new brush from the canvas.
- if you switch brushes without sending #with:, it gets used implicitly 
with an empty block.

This probably doesn't make much sense without an example, so - say you 
wanted an anchor, with an action, around an image.  With the current 
renderer it would look like this:

html anchorWithAction: [self doSomething] do: [
	html attributes border: 0.
	html imageWithUrl: 'foo.jpg'.
].

With the canvas, it would look like this:

html anchor action: [self doSomething]; with: [
	html image
		border: 0;
		url: 'foo.jpg'.
].

To give another example:

html textInputWithValue: foo callback: [:v | foo := v].
html textInputOn: #bar of: self.

becomes:

html textInput value: foo; callback: [:v | foo := v].
html textInput on: #bar of: self.

The major advantage, of course, is that there's a separate class for 
each brush type (to begin with, one brush for each tag, though I expect 
more complex brushes to come later), so instead of a monolithic 
renderer protocol with hundreds of methods, the behavior gets split 
across many more classes.  However, it manages to feel quite similar to 
what people are used to, and it's still completely streamable.  The 
other advantage is that you get a direct reference to the tag (brush) 
of interest, and can know, for example that you're setting attributes 
on the right thing, so problems like the one David pointed out wouldn't 
occur.

Avi