Re: how to render access to a JS argument variable?

Hi,

> jQuery’s replaceWith accepts either an html string or a javascript function.

I was looking at the JQuery API at

   http://api.jquery.com/replaceWith

which says it can take a "htmlString or Element or Array or jQuery",
OR a Function.  I mistakenly thought Seasides helper methods could
support all the types.  They don't.

> I believe this is also true for the Seaside binding implementation.
> Does the following code not do what you want?
>
>  html script defer with:
>           ((html jQuery id: buttonId) onClick:
>                ((html jQuery id: replacementId) call: 'replaceWith' with:
> ajaxRequest asFunction)).

Yes, call:with: does.  I was just suprised that Seaside's helper
method, JQueryInstance>>#replaceWith: can only support the htmlString
argument variation, not Element nor Array nor jQuery nor Function.
For those, one must write the #call:with: variation.  Given all the
other ways Seaside lets me write terse code, I was fooled for an
entire afternoon into thinking I could shoe-horn it in via
replaceWith: helper method.    :/

> The JSObject>>render: method should always produce a string, as it is called
> when the object needs to be rendered on a stream. It does not produce a
> ‘javascript string’.

Hm, looking closely, it seems like replaceWith: does only ever produce
a javascript string.  By the implementation passing in a String from
render::

    self call: 'someFunction' with: (self render: aRenderable)

and by call:with: implemented as:

    self call: aString withArguments: (Array with: anObject)

then what we get for the withArguments: is always an Array of one
String, which is rendered in double-quotes as a javascript "string".

It seems like if the replaceWith: were implemented as:

     self call 'replaceWith' with: aRenderable

then maybe they could support all the argument variations specified at
api.jquery.com, and not only the String variations.

And, indeed, the *vast majority* of senders of call:with: simply pass
the argument directly, thus truly providing merely the syntactic sugar
and nothing more..  But, for some reason, #after:, #append:, #before:,
#html:, #prepend:, #replaceWith:, #wrap:, #wrapAll:, #wrapInner: all
have that (self render: aRenderable) which forces the String arg...