[Seaside] render methods vs non-render methods in components - convention?

John Thornborrow john at pinesoft.co.uk
Mon Mar 31 16:59:01 UTC 2008

As the others have said, anything that renders goes into #rendering

callbacks go into #callbacks, and are logically named to be callbacks.
The only "on-the-fence" items are html updater "callbacks":

html anchor
 onClick: (html updater
  id: 'foo';
  callback: [:ren | self renderDivOn: ren ];
  return: false);
 with: 'update foo'

Otherwise a callback is logically named.

html anchor
  callback: [ self updateFoo ];
  with: 'update foo'



Randal L. Schwartz wrote:
> Briefly, call:/answer: should *not* be used during a render, but only
> during a callback.  Render methods should all take an "html" parameter.
> Yet a typical WAComponent of mine will have methods of both types.
> And a WATask will have *no* render methods.
> I'm wondering if there's a convention for me to know whether I'm in a render
> method (or something called from that) or not.  Do the experienced seasiders
> follow the convention that all render methods look like:
>     renderFooOn: html
> But what about the other methods?  How would you know if another method
> is being called from a render method or from a callback, or maybe both?
> In other words, is there a convention for me to know if I can call:
>    aValue ifNil: [aValue := self request: 'How many times?'].
> safely in a given method of a component?
> Should I put all callback support into a separate protocol category?

John Thornborrow

Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

More information about the seaside mailing list