I haven't looked in dept into the jetty feature but as far as i know
jetty hold the connection open. It pools it internally and when a request
(from the client)
comes in that connection is used and the request is pretty much handled like
a normal servlet request.
The problem is how and where does your code run when you get a server side
event
that then takes the connection from the pool again and sends something to
the client
(without the client requesting really for something)
Can you ask jetty "he i want to talk to that client, give me the socket
connection"
so where do you "wait" would that be in wicket code or can that be in jetty?
Because if that was in wicket code then we have to build in some support
because else the page(map) is locked for anything else constantly.
Johan
P.S. Repeater package is just something much newer and better then ListView
they are
separate things and are a bit different in design.
On 2/28/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
Hi All,
I'm currently developing an application in which I need some kind of
push technology, and even if wicket doesn't seem to support such
feature for the moment, it seems that the gates are open to implement
my own. Great design, kudos to the wicket team!
I'd like to share with you my ideas about that, so that you can
correct me if you think I will hit a wall, or tell me if others have
already done things like what I need. My idea is also to make
something generic that could later be used by other wicket users, and
I'd need your feedback on the different strategies I see.
Disclaimer: I'm a wicket and web development newbie, so these ideas
may suffer from serious design flaws :-)
1) "push" support in wicket
--------------------------------------
For the moment as far as I understand wicket it's not possible to
trigger an update of a client on a server side event. My idea is to
add an interface very similar to the AjaxRequestTarget class, on which
you could call the addComponent and append/prependJavascript to
trigger the appropriate events on the client. To control event
propagation atomicity, I would add a trigger() method which indicates
that the events (component refresh, javascript calls) added so far are
ready to be sent to the client.
I would also provide a class implementing this interface and the
IBehavior, so that you can easily add an instance of this class to
your page and trigger events from the server side.
This implementation would actually contribute a javascript to the page
to poll the server for changes, at a configurable rate, much like the
AbstractAjaxTimerBehavior is implemented. The difference would be that
instead of calling the onTimer(AjaxRequestTarget) in the respond
method it would actually "copy" all the components and javascripts
"server-side events" that were added on the object to the
AjaxRequestTarget. Obviously I would need to take care of thread
synchronization issues.
This seems pretty simple and I think it can be implemented without any
modification in Wicket. But maybe this is something that could be
interesting to contribute to the wicket community?
2) finer grain component update
---------------------------------------------
In some cases refreshing a whole component in ajax in too coarse
grain. Imagine you want to implement a chat application. If you add
the component resonsible for rendering the messages history (probably
a ListView or RepeatingView) to your AjaxRequestTarget, you will
actually transport the whole rendered component to the client each
time a new message should be appended to the list. This is not really
optimal.
Thus I'd like to implement this kind of fine grain update, and I think
I can do it by calling addJavascript instead of addComponent, with the
appropriate javascript. But it would be much cleaner to add a method
to AjaxRequestTarget allowing to insert a new item in a RepeatingView
or ListView. If I patch wicket to do that, is it something that would
have a chance to get integrated in wicket?
BTW, any reason why ListView is not a subclass of RepeatingView? It
would make my development cleaner, and it seems pretty easy to make
ListView inherit from RepeatingView.
3) more scalable refresh
--------------------------------------
The problem with the solution proposed in 1) is that you have to
configure your poll rate. If you set it up with a very frequent rate,
HTTP connections will be opened frequently, decreasing service
scalability, especially with the one thread per request model used in
most web servers. Therefore a better solution would be to use a push
technology such as cometd, for which we can find implementations
relying on NIO and thus bypassing the limitation of one thread per
request (see jetty cometd implementation, or the grizzly connector for
glassfish).
As usual I can implement a solution on top of Wicket, but a better
integration could be interesting for others (and for me). So my idea
here is to provide another implementation to the interface described
in 1), which post an event on a cometd topic each time the trigger()
method is called. On the client side, a javascript would register on
this topic, and whenever a message is received it would convert it to
a call to the same method that is called when an ajax response is
received (Wicket.Ajax.Call.loadedCallback I think). The main
difference between the two would be that in pure ajax the answer is
received as xml directly, while cometd force the answer to be in json.
Therefore the cometd event would be a very simple json object with one
main property: a string containing the xml that is usually send
directly. This is not really in the spirit of json and cometd, but
would make an easy fit in the existing design of wicket-ajax.
So, what do you think of these ideas? Do you think they could be in a
good direction? Do you think others might be interested? Should I
prefer the "work on my own way" flavor or the "patch to wicket" one?
Would the last point fit in the wicket-contrib-dojo spirit?
Thanks in advance for your feedback, and congratulations if you've
read so far :-)
- Xavier
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
