[Seaside] More S-Exprs

[Jim Benson]

Avi,

> Ok, right.  I wonder if it's best to not use the href="@foo" notation
> in the tutorials, that might lead to less confusion.
> As I think I pointed out before, you *could* write, in sexprs,
>
> (a href: '@edit:' '(edit)')
>
> But I find that less natural, personally.
>

Hmm, I don't recall any mention of the S-Exprs in the tutorials. I'm just
personally wierd when I see the @ sign in something, my first exposure to
that symbol was in the programming language Forth where it means
indirection. It took me forever and a day to see 10@34 as a Point in
Smalltalk.

I think that the only way I could figure this out will be after creating
quite 40 or 50 web pages, to see which I prefer, and by then it wouldn't
matter.

I can see the case of viewing the language form:

#(table
   (tr sea:id: 'app/apps'
      (td (a sea:id: appLink target: seasideapp '[app.key]'))
      (td (a sea:id: edit: '(edit)'))
      (td (a sea:id: remove: '(remove)'))))

as:

#(table
    ( tr repeat: '@app/apps'
      (td (a href: '@appLink' target: seasideapp '[app.key]'))
      (td (a href: '@edit:' '(edit)'))
      (td (a href: '@remove:' '(remove)'))))

as a more straightforward 'translation' of the HTML that will be generated
at the end of the day. Another question is how do you find syntax errors, or
where something bad happened? If I'm just looking through a bunch of sea:id:
tokens that doesn't give me much of a clue.

>From an application programmer mindset, conceptually I have all of the HTML
elements that get generated, and the S-Expr automagically closes ( </term> )
them for me. Then I just read the "@term" as an action, which would have a
corresponding method, in the case of everything except the language elements
for repeat and conditionals. In the case of the additional language
elements, you'd just have to know (as on page 1 of the definitive Seaside
guide) what those language elements are. In other words, if you're coming
from HTML or probably Squeak land, and less from Lisp land, you can "see" a
little better what it's doing, though that might not be what's happening
under the sheets.

Plus, in the first case, it's not clear that there is a repeat: statement by
a simple glance. There are so many things surrounded by single quotes, you
may miss the / as the loop indicator.

That's basically the same complaint as:

border = 0

being rewritten as:

border: '0'

coming from Squeak land, it's not as attractive as saying, "border: 0"

With that said, it not quite sure how more powerful macros fit in the
scheme. My guess is that someone hands me a HTML page that I have to
translate into a Seaside #html method. Server side logic says that you need
more "Umph" so you need a macro of some sort. I guess at the of the day, the
less I have to type, or hopefully machine translate, the better.

Notice that one thing in the above example that obscures what is going on in
the S-Expr world is the (edit) and (remove) statements. For other readers,
these spit out text that includes the parens. They don't really have
anything to do with the S-Expr itself, just a bad selection of example.


> To make something clearer: the transformation that's happening at this
> level is from href->sea:id, not the other way around.  That is, <a
> href="@foo"> gets translated to <a sea:id="foo">.  The sea:id
> attribute is the canonical form, which is why I don't bother using
> anything else in the s-epxr templates.  That's also why it's irrelevant
> what attribute you use (href/repeat/foo) because it all becomes a sea:id
> once its parsed.  The only purpose of the @ notation is that it lets us
> sneakily use whatever little fields are provided in dialog boxes in
> WYSIWYG editors to enter in the info which is actually important, ie, the
> sea:id.
>
> Now, there is a separate "transformation" of sorts that happens much
> later, when the element actually generates html, and then, indeed, an href
> will be printed out... but that's a different kettle of fish.
>
> Making any sense?

Yes, it's starting to sink in.

Jim