Hello list, I was wondering if it's possible to create an instance of SUUpdater without using the normal: (html updater) id: 'anID'; callback: [:renderer | someNiceRendering ].
If I do the following: updater := SUUpdater new. updater url: 'http://localhost:8080/seaside/meteoroid/counter'. " == html context actionUrl withoutParameters" updater addParameters: #('_s'->'GaMJovPCAHDxFKZT' '_k'->'VLnoRkpz'). " == html context actionUrl parameters" updater id: 'anID'; callback: [:renderer | someNiceRendering ].
It generates a JS(*), but when it renders the Update it does inside a div, not inside the body. (*) meteoroid.eval('new Ajax.Updater('count',' http://localhost:8080/seaside/meteoroid/counter ',{'evalScripts':true,'parameters':['_s=GaMJovPCAHDxFKZT','_k=VLnoRkpz'].join('&')})')
So, It's possible to create a SUUpdater without the normal html? (of course, it has to work in an page)
Thanks in advance Lautaro Fernández
PS: Why do I need this? because I'm doing a rendering process inside a model and I'm inserting that updater into the page via Comet, but I don't want to keep the 'html' inside the page as an instance variable, just the values I need (like the url and the parameters).
So, It's possible to create a SUUpdater without the normal html? (of course, it has to work in an page)
Not without other hacks. The updater needs to know the render-context to be able to register the callbacks. That's a bit ugly in Seaside 2.8 and we were recently discussing on fixing that dependency in Seaside 2.9, but we didn't do it yet. Maybe a feature request in the issue tracker would put some pressure on us ;-)
PS: Why do I need this? because I'm doing a rendering process inside a model and I'm inserting that updater into the page via Comet, but I don't want to keep the 'html' inside the page as an instance variable, just the values I need (like the url and the parameters).
It sounds a bit ugly, that the model needs to know about the view. What about applying the observer pattern (or one of its incarnations), so that the view gets notified about changes in the model? Like this your model and view would be separated and you could create the script from the right context.
Cheers, Lukas
2009/2/25 Lukas Renggli renggli@gmail.com
Maybe a feature request in the issue tracker would put some pressure on us ;-)
I'll report it tomorrow
PS: Why do I need this? because I'm doing a rendering process inside a
model
and I'm inserting that updater into the page via Comet, but I don't want
to
keep the 'html' inside the page as an instance variable, just the values
I
need (like the url and the parameters).
It sounds a bit ugly, that the model needs to know about the view. What about applying the observer pattern (or one of its incarnations), so that the view gets notified about changes in the model? Like this your model and view would be separated and you could create the script from the right context.
I had simplified the context of our framework, our model indeed does not know anything about the observers. What it does(the model) is to trigger an Announce, and then (via announcements mechanism) all the dependents get that announce. The ugly part, is that we use blocks to "render the announcers" and therefore we need to put the html inside the block, or inside the web page.
We will see if doing more hacking or just simply add the html is good for us. As always, thanks for your quickly response. Lautaro Fernández
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Here is an example of what we want to do:
*anAnnouncerModel* when: *ExampleAnnouncement* do: [:anAnnouncement :anAnnouncer | aCometPage push: ( (html updater) id: aDOM_ID_OfTheAlreadyRenderedPage; callback: [:renderer | do some stuff with the renderer]; yourself ) ]
The time line will be as follow: 1.- first we delivered a web page into the browser 2.- at some point, the model change and triggers an announce: * ExampleAnnouncement *3.- the already rendered page( 1.- ) get notified 4.- the already rendered page push an AJAX JS into the browser using the block we had put some lines above
We can do this keeping the 'html' when the page is rendered, and with that 'html' we create a SUUpdater and then we push it into the browser. But we think that's a wrong approach to solve this issue.
So, if you thinks there is another better way, would be nice to hear of it. Bye!
I don't know if it's a "better" way, but that looks like what we've done in SmallFaces (without Announcements and Comet), you may take a look there. Spanish documentation is here : http://cs.hernanmorales.com.ar/projects/smallFaces/sf-es.php and english version here: http://wiki.squeak.org/squeak/6088
Hernán
2009/2/25 Lautaro Fernández evaklo@gmail.com:
Here is an example of what we want to do:
anAnnouncerModel when: ExampleAnnouncement do: [:anAnnouncement :anAnnouncer | aCometPage push: ( (html updater) id: aDOM_ID_OfTheAlreadyRenderedPage; callback: [:renderer | do some stuff with the renderer]; yourself ) ]
The time line will be as follow: 1.- first we delivered a web page into the browser 2.- at some point, the model change and triggers an announce: ExampleAnnouncement 3.- the already rendered page( 1.- ) get notified 4.- the already rendered page push an AJAX JS into the browser using the block we had put some lines above
We can do this keeping the 'html' when the page is rendered, and with that 'html' we create a SUUpdater and then we push it into the browser. But we think that's a wrong approach to solve this issue.
So, if you thinks there is another better way, would be nice to hear of it. Bye!
-- Luke LAut SkyFernadezWalker
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Thanks Hernán, but finally we decided to use the html in a different way. Instead of keeping the html in the rendering face #renderContentOn: we use a JavaScript which calls a message implemented by us. In that call we give as parameter the "renderer" which is the html. Is kind of the same, but a bit nicer.
Thanks for your time, Lautaro Fernández PS: I'll check anyway your URLs, thanks for that
2009/3/2 Hernán Morales Durand hernan.morales@gmail.com
I don't know if it's a "better" way, but that looks like what we've done in SmallFaces (without Announcements and Comet), you may take a look there. Spanish documentation is here : http://cs.hernanmorales.com.ar/projects/smallFaces/sf-es.php and english version here: http://wiki.squeak.org/squeak/6088
Hernán
2009/2/25 Lautaro Fernández evaklo@gmail.com:
Here is an example of what we want to do:
anAnnouncerModel when: ExampleAnnouncement do: [:anAnnouncement :anAnnouncer | aCometPage push: ( (html updater) id: aDOM_ID_OfTheAlreadyRenderedPage; callback: [:renderer | do some stuff with the renderer]; yourself ) ]
The time line will be as follow: 1.- first we delivered a web page into the browser 2.- at some point, the model change and triggers an announce: ExampleAnnouncement 3.- the already rendered page( 1.- ) get notified 4.- the already rendered page push an AJAX JS into the browser using the block we had put some lines above
We can do this keeping the 'html' when the page is rendered, and with
that
'html' we create a SUUpdater and then we push it into the browser. But we think that's a wrong approach to solve this issue.
So, if you thinks there is another better way, would be nice to hear of
it.
Bye!
-- Luke LAut SkyFernadezWalker
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside@lists.squeakfoundation.org
-
Hernán Morales Durand -
Lautaro Fernández -
Lukas Renggli