[Seaside] new bindings system

[Jim Benson]

Avi,

> The WebObjects folks will hate me for this, but I think it'll be
> worthwhile for everybody else.  But let me know what y'all think.
>

I say let the WebObjects folks fend for themselves, I've got work to do.


>
>    (template elementNamed: 'someInput')
>      bind: #value toPath: 'item.name'
>
> You would now write as:
>
>    (template elementNamed: 'someInput')
>       onDisplay: [:input | input value: item name];
>       onUpdate: [:input | item name: input value].
>
> This is more verbose, but it also has (IMO) much clearer semantics.
>

The 'item.name' doesn't quite look right. That's probably a good change.

As a newbie I don't much experience using Seaside just yet, but let me just
give you my take on the rest of your proposal. If I understand it correctly,
basically you introduce blocks for the basic bindings. This has always been
the very seductive dark side of the force to me. Conceptually, I can build
these wonderfully complex behaviours and just shove them where I want them.
I can build very complex apps fast.

However, one of the drawbacks of this approach is that it's a real bitch to
debug, especially if you are in a large or legacy system. You usually start
out with these simple, easy to understand little blocks and it all seems to
just flow together when you  *build* the app. When another person comes
along and tries to figure out what's going on, it's difficult to pinpoint
where the different blocks are defined in the source code. You just know
eventually someone will override a block definition in one of the bindings
from a point external to the initial definition.

Squeak's debugger doesn't help as much as it should in these cases. Figuring
out "where to break" is especially true in under-documented system (but the
code that *we* write is so intuitive it probably doesn't need much debugging
or documentation, right?). Plus there's the block-closure problem that may
bite you when least expected.

With all that said, you can probably tell me if the trade off of the power
of the proposed changes outweigh the disadvantages of maintenance and
debugging. If it's a big win, I like it. If it's a slight loss or toss up,
you might want to consider a more traditional implementation such as the way
Squeak handles events with #on:do:with: ,  or make an explicit method call.
It's not as flexible, or syntactically elegant, but something to consider.

With all that said, I like the blocks approach ;-) But then again, I always
liked Darth and the Emperor better than the green puppet with the Fozi Bear
voice.


> One side effect of this proposal is that templates are now cached at the
> instance level, not the class level.  This does entail a little more
> memory usage and more invocations of the parser.  If it becomes a problem
> we can find ways to optimize it.
>

I wouldn't worry too much about memory. People seem to worry alot about
'saving' it, like it's part of a damn rainforest or something. Memory's
cheap.


Jim