render methods vs non-render methods in components - convention?

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?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>  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

Exactly, and put it into a category called #rendering.

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

Exactly the same pattern, call it #render([A-Z][a-z]+)*On: and put it
into a category called #rendering.

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

You give it an intention revealing name ;-)

>  Should I put all callback support into a separate protocol category?

I mostly put these into a category called #actions.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>>>> "Lukas" == Lukas Renggli <[hidden email]> writes:

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

Lukas> Exactly the same pattern, call it #render([A-Z][a-z]+)*On: and put it
Lukas> into a category called #rendering.

Well, what I'm thinking about is the auxiliary methods?  Maybe it's
always obvious, but I'm thinking about the case where sometimes a
callback method would call it, and sometimes a render method would
call it.  I'm wondering if I'm thinking about a case that usually
doesn't happen, or whether this actually does run into trouble.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> >     renderFooOn: html
>
> Exactly, and put it into a category called #rendering.

Same here!

>
> >  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?
>
> Exactly the same pattern, call it #render([A-Z][a-z]+)*On:
> and put it into a category called #rendering.

Same here!

>
> >  Should I put all callback support into a separate protocol
> category?
>
> I mostly put these into a category called #actions.
>
> Lukas

Same here!

> Well, what I'm thinking about is the auxiliary methods?  
> Maybe it's always obvious, but I'm thinking about the case
> where sometimes a callback method would call it, and
> sometimes a render method would call it.  I'm wondering if
> I'm thinking about a case that usually doesn't happen, or
> whether this actually does run into trouble.

I just don't see this happening in my code.  Component transitions are
almost always bound to some user action so it's pretty clear just from the
method name (#save, #cancel, #search, etc.) that this method is used in a
callback.

Ramon Leon
http://onsmalltalk.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside