[Seaside] click images and questionable API

[Nevin Pratt]

adi at netstyle.ch wrote:

>Hi Nevin
>
>Try this (see WAHtmlGenerator):
>
>aRenderer inHeadDo: [
>    aRenderer attributeAt: 'NAME' put: 'Foo'.
>    aRenderer attributeAt: 'CONTENT' put: 'Some description of Foo'.
>    aRenderer tag: #meta]
>
>and...
>
>aRenderer title: 'Title'.
>
>Adrian
>  
>

Thanks, Adrian.  Yes, it worked.  But then, you already knew it would :-)

As usual, it is embarrassingly easy once you know how.  I guess the main 
problem is the lack of documentation, or at least, we need some more 
sample code.

My next problem is creating images that are links, like the following 
html would do:

   <a href="http://www.ebay.com"><img src="/images/ebay"></a>

It's not immediately obvious how to get Seaside to generate this type of 
html.  I've looked a little at the #imageFromForm: and 
#imageMapWithAction:form: methods.  It seems intuitively the latter 
method would be what I want, but it's not obvious if it is, or if so, 
how to use it.

So how would I generate html like the above (aside from coding it 
directly in a #text: message)?

And actually, this brings up the next question.  First, consider the 
code you provided, above:

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.

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.

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), 
because both examples require you know about the html meta tags, and 
require that you know precisely what it is you are trying to build.

So, what exactly do you see as the advantage of Example #1, over Example #2?

OK, here's another example:

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?

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:).

There seems to be a lot of extra API to learn for no real gain.  But I 
think you guys are smart guys.  There's got to be something I'm not 
considering.

Nevin