[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'
Regards,
John
www.pinesoft.co.uk
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
http://www.pinesoft.co.uk
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