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). -- Luke LAut SkyFernadezWalker _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> 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 -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2009/2/25 Lukas Renggli <[hidden email]> Maybe a feature request in the issue I'll report it tomorrow
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
-- Luke LAut SkyFernadezWalker _______________________________________________ seaside mailing list [hidden email] 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! -- Luke LAut SkyFernadezWalker _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
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 <[hidden email]>: > 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 > [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 |
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 <[hidden email]> I don't know if it's a "better" way, but that looks like what we've -- Luke LAut SkyFernadezWalker _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |