[Seaside] click images and questionable API

[Avi Bryant]

On Thu, 20 Mar 2003, Nevin Pratt wrote:

> EXAMPLE #1:
>
> aRenderer inHeadDo: [
>     aRenderer attributeAt: 'NAME' put: 'Foo'.
>     aRenderer attributeAt: 'CONTENT' put: 'Some description of Foo'.
>     aRenderer tag: #meta]
>
> Now, compare this with the following:
>
> EXAMPLE #2:
>
> aRenderer inHeadDo: [
>     aRendered text: '<meta NAME="Foo" CONTENT="Some description of Foo">']
>
> Example #1 is four lines of code.  Example #2 is two lines, and seems to
> me to be simpler.

Yes, but why would you use either directly?  Add a method to renderer so
that you can do

aRenderer metaTagNamed: 'Foo' content: 'Some description of Foo'.

Or,

aRenderer metaTags: {'Foo' -> 'Some description of Foo'. 'Bar' -> '...'}.

That may not seem much of an advantage when using literal text, but what
if those are variables instead?  Then your simple use of #text: becomes

aRenderer text: '<meta name="',someName,'" content="',someContent,'">'

It also gets ugly when your content has a $' in it, etc...

> Example #1 also has (I think) a time-dependence element to it,
> controlling which tag the #attributeAt:put: is going to be applied to.
>  Example #2 makes it obvious, and has no such time-dependence.

The purpose of having the #attributeAt:put: separately from the method
creating the tag is that most of the time, you don't need any extra
attributes.  You could of course have variations of every single rendering
method with and without an attributes: keyword, but I wasn't interested in
bloating the API to that degree.  Allowing attribute methods and tag
methods to be "composed" (yes, unfortunately in a sequential manner that
allows for errors of usahe) was the best compromise I could come up with.

> Example #1 does not really move you away from needing to know html
> (assuming that was a goal, which might be a bad assumption on my part),

It is not a goal.

> EXAMPLE #3:  aRenderer horizontalRule
> EXAMPLE #4: aRenderer text: '<hr>'
>
> They both do the same thing, don't they?  And, people coming to Seaside
> are going to be more used to code like Example #4, are they not?  Then
> what exactly is the advantage of Example #3, anyway?

I can see the argument for using an #hr message instead of (or as well as)
#horizontalRule - I have a personal preference for descriptive names, but
familiarity and concision are also useful.  The 2.3 snapshot includes a
DNU on renderer so that you can use #hr (or any other tag name) if you
want.

I don't see any gain in

aRenderer text: '<hr>'
over
aRenderer hr

however.

> Seaside seems to be full of this kind of stuff, where I don't know if I
> even want to bother learning the API, but rather just write the stuff in
> a #text: message instead (of course, writing it in a #text: message
> wasn't putting it in the header, so I really did need to know about
> #inHeadDo:).

Feel free.  But do you really want to be writing

html text: '<table>'.
...
html text: '</table>'.

and so on instead of

html table: [...] ?

And  there are some places where you'll have to use the API - for example,
to create links or inputs with callbacks.  So your code will be an odd mix
of straight html and higher level methods.

But I've taken a fair amount of care to allow most of Seaside's features
to be used independently of one another - there's no reason you
necessarily have to use HtmlRenderer at all if you have some other way
you'd prefer to do things (and in fact Colin Putney was working on some
alternatives before he ran away to Mexico for the month ;).

Avi