Is there any reason not to push systematically on every component update ? The bytes have to go to the client anyhow, and the channel is open. In other words, make pushing the default instead of pulling.
Someone more familiar with ICEPush will correct me if I’m wrong, but I’m under the impression that the add-on works by sending a nudge to the client when the server side push() is called, and the client will then perform a normal server roundtrip that pulls any pending changes and renders them. This would mean that it’d be more efficient to send the changes in batches instead of doing that roundtrip for every component tree change.
It’d be trivial to add a thread in the server that just calls push() periodically, but I don’t think this has any real upsides over client side polling with eg. the Refresher add-on. The current ICEPush add-on allows the developer to control the “transaction” and “commit” the changes to the client in suitable batches, which I think is the best option even if it requires some legwork for the developer.
I suspect you are right “push()” is in fact “nudge to pull”.
But the “suitable batch” is what I’m after.
Is there any reason to batch at all? If I am updating several components in response to an event, it is probably easier to update each component and nudge right away (this keeps the logic simple). In that way I don’t have to keep track of whether I am done updating the components on a window (and wait until I am done with the window to issue the nudge).
Indeed, that is how it works. ICEPush just provides a notification channel from the server to the client.
I can think of cases where you do not want to push after each component update, for instance when adding components to or removing components from a layout. Wouldn’t look very good if the intermediate state was shown to the end-user.
When I find some time I will investigate how ICEPush could be better hooked into the Vaadin core. Vaadin provides a RepaintRequestListener which is fired every time a part of a component is updated. By listening to this ICEPush could know what is going on and for instance when there has been no repaint events for X ms it could push the changes automatically. Then you wouldn’t need to call push() yourself, unless you absolutely want to push the changes immediately when they have been made.
I added another demo for the ICEPush add-on, this time a multi-user calendar based on Vaadin Calendar.You can check it out at
http://artur.virtuallypreinstalled.com/MultiUserCalendar/
Wow - this is a really nice demo.
Please, do that !!! ICEpush would become then as great extension.
If you need consume one (or more) thread consider method that allow user to provide it own instance of java.util.concurrent.ScheduledExecutorService (or maybe it is already available in server side Vaadin?). For example this will allow me to connect threads that you will need with my thread pool for Scala actors.
Thanks:)
I am unable to get the demo to work from source. (checked out from the incubator)
(there is no such class in the source).
I am also unable to get my own code to work. I have followed the instructions and changed the servlet as indicated.
Things appear to be working on the server side. For example, I got a meaningful message when trying to push without adding the pusher to the main window, and adding the component as in the demo made the error go away.
My problem is that pushing doesn’t. I was setting the value of a label before pushing, no changes. I tried replacing the component as something more drastic, no changes.
When inspecting the page with Chrome, I see the inclusion of the icepush.js (but no apparent javascript invocation to that code).
As a last ditch attempt, I added the two lines found in the demo’s widget set definition, such that the end of my file is now
[code]
<inherits name="org.vaadin.artur.icepush.IcepushaddonWidgetset" />
<inherits name="org.icepush.gwt.ICEpush" />
<!-- adding support for icepush -->
<script src="icepush.js"></script>
[/code] (the bottom two entries were not present with automatic recompile)
All this under Vaadin 6.3.3.
So to recap:
- Where can we find the current source to the demos
- Is there a debugging setting I can turn on in ICEpush or your code to get more information as to why pushing doesn’t
There was a problem with the web.xml in the repository (referred to the wrong class). The correct demo class is org.vaadin.artur.icepush.example.ICEPushDemo, which the web.xml in incubator now also refers to.
What you should see with Firebug or another tool that displays the requests is
- GET icepush.js → returns the icepush javascript
- POST create-push-id.icepush
- POST add-group-member.icepush
- POST listen.icepush → This request should remain open until you call push() on the server side
There might be a problem with the URL you use. If the requests fail or are sent to the wrong URL, try adding a / at the end of the URL (http://artur.virtuallypreinstalled.com/MultiUserCalendar seems to fail even though http://artur.virtuallypreinstalled.com/MultiUserCalendar/ works). It seems to be a problem with how icepush.js generates the push URL, need to investigate this more…
There should be no need for this. Your widgetset includes the IcepushaddonWidgetset, which in turns includes the required files.
Aha! Adding a / at the end indeed makes things work! You made my day, but please add this to the notes on the directory !
hi Arthur,
Understand that ICE push has only servlet deployment support… as am getting runtime exception for my liferay portlet
Recently, Seen that ICEpush have added support portal support too
http://jira.icefaces.org/browse/PUSH-65?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
Any idea how this can be intergrated with Vaadin addon
Appreciate all your advice
thanks and regards
Joseph
Hi Arthur,
Could you pls tell us when we can this add-on that works for Portlet application as well?
I am unable to integrate this with portlet application.
Thanks,
Trivedi