How to perform some action on every page refresh?

Hi,
In my application i have this section where i list clients, but i need
to have that list update everytime the user refreshes the page and not
through a specific link or form field. What would be the most correct
way to achieve this?

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

> In my application i have this section where i list clients, but i need
> to have that list update everytime the user refreshes the page and not
> through a specific link or form field. What would be the most correct
> way to achieve this?

Every time you get a page refresh Seaside re-generates the specific
page. Seaside calls your #renderContentOn: messages every time the
user hits refresh.

Or did you ask something else?

Lukas

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

Perhaps the question was triggered when the list didn't change, which may be the case if its initialized once for the first rendering pass, but second pass simply uses stored collection after. If the list is generated and needs updating, just don't store it.

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: Seaside - general discussion <[hidden email]>
Sent: Sat Sep 15 04:16:25 2007
Subject: Re: [Seaside] How to perform some action on every page refresh?

> In my application i have this section where i list clients, but i need
> to have that list update everytime the user refreshes the page and not
> through a specific link or form field. What would be the most correct
> way to achieve this?

Every time you get a page refresh Seaside re-generates the specific
page. Seaside calls your #renderContentOn: messages every time the
user hits refresh.

Or did you ask something else?

Lukas

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

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

If I understood you right, you need what Lukas told. Just use the
#renderContentOn: of the compoenent like this:

ClientsList>>renderContentOn: html

        self freshClients do:[:e| self renderClient: e on: html]
       

Then your method #freshClients gets them from whatever you are using to
store and query clients. Everytime the component is rendered (visited or
refreshed) you have the Seaside guarantee of that being executed

        cheers,

Sebastian Sastre


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

First let me thank everyone who answered my question.

Sebastian Sastre wrote:
I must admit this was my first thought, but i actually believe i read
somewhere that one should not call non-rendering methods from
#renderContentOn:.

Thanks again everyone for your answers.


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

2007/9/16, Alexandre Paes <[hidden email]>:
Because that's true. You should never send #renderContentOn: to a
component. You should always send #render: to the canvas with the
component as an argument.

Cheers
Philippe

> Thanks again everyone for your answers.
>
>
> Alexandre
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Well, as Phillipe said renderContentOn: should not be called because Seaside
guarantees it's call. But you can allways send a component to render using
#render: (and including it's instVar in #children)

See:

        Clients
                clientsHeader
                clientsList


Clients>>renderContentOn: html

        html div class: #clientsHeader; with: [render: clientsHeader].
        html div class: #clientsList; with: [render: clientsList].

Clients>>children
        ^ {clientsHeader. clientsList}

But when is rendered you want guarantee fresh clients, so that's the moment
to provide fresh clients, so that’s when you call them.

By default is less error prone to think "I cant call method in
renderContentOn" but actually you can call non rendering methods but you
just use significant discern for what you're doing calling them (to evade
interference with rendering process, coupling, other bad guys) so to be
aware of it's consequences,

Cheers,

Sebastian

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

Em 09/16/07 13:52 Sebastian Sastre escreveu:

> Well, as Phillipe said renderContentOn: should not be called because Seaside
> guarantees it's call. But you can allways send a component to render using
> #render: (and including it's instVar in #children)


> But when is rendered you want guarantee fresh clients, so that's the moment
> to provide fresh clients, so that’s when you call them.
>
> By default is less error prone to think "I cant call method in
> renderContentOn" but actually you can call non rendering methods but you
> just use significant discern for what you're doing calling them (to evade
> interference with rendering process, coupling, other bad guys) so to be
> aware of it's consequences,



Thanks Phillipe, Sebastian and everyone for the help with this subject,
it all makes a lot more sense right now. And above all, it's working
perfectly now :D



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

Using almost latest seaside and scriptaculou , I am rendering a button
like so:

renderEditorButtonAddOn: html
    | addId  |
   
    html submitButton
        id: (addId := html nextId);
        onClick: (self renderUpdaterElement: addId on: html);
        callback: [ self add ];
        text: '>>'.

The following code works (although there is a fleeting js error)

renderUpdaterElement: eid on: html
    (html updater
        id: id;
        triggerFormElement: eid;
        on: #updateEditorOn: of: self;
        return: false)

But this code doesnt work

 renderUpdaterElement: eid on: html
    ^ (html updater
        id: id;
        triggerFormElement: eid;
        on: #updateEditorOn: of: self;
        return: false)

any ideas why not?

thanks in advance

Keith


p.s. if I replace submitButton with button, I get a minicule-tiny-button
once more.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Could you please post a file-out of your problem that is
on-click-runnable and shows the bug? I am unable to properly reproduce
the problem after implementing all the missing parts myself :-(

In the process I observed the following problems:

> The following code works (although there is a fleeting js error)
>
> renderUpdaterElement: eid on: html
>     (html updater
>         id: id;

I don't have a variable 'id'?

>         triggerFormElement: eid;

Buttons are ignored, so this won't work if your target element is a
button. See the method comment of #triggerFormElement:

"Serializing a form element and trigger its associated callback. Note
that this might not work for all form elements as one would expect:
(1) check-boxes and multi-select lists do not work as Seaside
internally depends on other hidden form elements. (2) submit-button
callbacks are ignored, instead use the normal callback to trigger
specific code evaluation."

As a solution you might want to directly put the action into the
callback block (this is one of the rare places where model-changes and
rendering are in fact supposed to happen at once).

> p.s. if I replace submitButton with button, I get a minicule-tiny-button
> once more.

#button requires #with: instead of #text:. Unfortunately #text: is
implemented in the superclass and silently ignores the request. I will
commit a version that throws an error soon. Again Traits would help to
avoid to have methods defined to high up the hierarchy.

Lukas

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

> Could you please post a file-out of your problem that is
> on-click-runnable and shows the bug? I am unable to properly reproduce
> the problem after implementing all the missing parts myself :-(

I had a look at the code at <http://mc.lukas.renggli.ch/pieraddons>.

There are several problems:

1. As I wrote previously, it is not possible to trigger buttons. You
need to add this action to the #callback:

2. You need to trigger both lists (not visible in the mail, but in the
code). Otherwise the two actions don't work.

Maybe, the whole code would be simpler if you only moved the DOM nodes
of the lists back and forth, without contacting the server.

Lukas

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