[Seaside] S-Exprs

[Avi Bryant]

On Mon, 27 May 2002, Tim Rowledge wrote:

> How about (h1: [question]) ?

Hmm, that's an interesting one.  The rule being, appending a colon to a
tag name means the entire contents should be treated as text?  So, for
example,

(p: This is a test).

I don't hate it.  What about when the tag has attributes?
(p: align: right This is a test) looks a little funny.  There's also a
problem if the first word of your text ends with a colon, since it will be
treated as an attribute.  So maybe that means that (p: align: right This
is a text) should be taken as (p 'align: right This is a test')?

> One thing I'd like to see attempted is a decent integration of
> _whatever_ syntax is used with the normal tools (or some decent
> alternative tools I suppose) for finding references. A major pain with
> ComSwiki is the complete inability to meaningfully track down senders
> and implementors, even with the swikibrowser.

Using the sexpr syntax definitely helps with this.  A couple of things
that might improve it:

- use/allow spaces instead of dots in paths.  Tim probably likes this one
anyway.  And then,

- allow a similar trick for attributes as the above for contents, giving

(input type: text sea:id: (item name))  instead of
(input type: text sea:id: 'item.name')

I'm more comfortable with this change, in fact, than I am with the other
one, because it's always clear what's an attribute value and what's not
just because of its position.  As for spaces vs. dots, I kinda like the
dot notation expressly because it doesn't look like message sends, and so
it's less confusing when it doesn't act exactly the same way.  But I
definitely see the advantages of letting 'find senders' do its job.