[Seaside] click images and questionable API

[Nevin Pratt]

>
>
>Feel free.  But do you really want to be writing
>
>html text: '<table>'.
>...
>html text: '</table>'.
>
>and so on instead of
>
>html table: [...] ?
>  
>

Now, hold on there... I didn't say *all* the API was questionable, now 
did I?!  :-)  I think your block argument methods are actually quite 
elegant.

>>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
>  
>

OK.  I see your point.  And of course, once one accepts 'aRenderer hr', 
it's not hard to see the "descriptive names" argument to get you to 
'aRenderer horizontalRule'.

But, I think I like your DNU solution for 2.3, though.

>...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,'">'
>

Well,  your example has literal text, too.  What if it was using 
variables instead?  For example, you mentioned:

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


What if instead of the literal 'Some description of Foo', you instead 
had a description that was built from variables?

In other words, your code seems to suffer from the exact same problem as 
well.  Besides, if it was such a big win, why haven't you added 
#metaTags: and #metaTageNamed:content: methods to the renderer already?

I'm being the devil's advocate here, but to be honest, I can feel myself 
being pulled your way even though I've thrown up another argument 
questioning it.

Let's look at another one of your examples:

>imageWithSource: srcUrl link: hrefUrl
>  self attributeAt: 'href' put: hrefUrl.
>  self tag: 'a' do: [
>    self attributes: {'border' -> 0. 'src' -> srcUrl}.
>    self tag: 'img'.
>  ]
>
>Then you would have
>
>html imageWithSource: '/images/ebay' link: 'http://www.ebay.com'.
>
>  
>

I like this.  But why wasn't #imageWithSource:link: in renderer already? 
 For some naive reason, I was expecting existing API to cover this case, 
as I thought it to be a fairly mundane, common case.  

And even though I bring up these questions, I still rate Seaside as one 
of the best (possibly *the* best) web development framework ever devised.

Nevin