Good morning, Would you mind sharing that library with us, please?
Regards, Pierre Goupil Le 8 mars 2017 09:28, "Gonzalo Aguilar Delgado" <gagui...@level2crm.com> a écrit : > Hi Martin, > > Thank you a lot. I'm almost done!!! > > It's so great. I made a clientside library that allows widgets to register > for data streams. And the Websockets library integrated with Wicket > subscribe delivers the specific data to each subscriptor. > > It takes just one connection. And I loooooove it! > > Best regards, > > El 07/03/17 a las 21:45, Martin Grigorov escribió: > > Hi, > > On Tue, Mar 7, 2017 at 10:07 AM, Gonzalo Aguilar Delgado > <gagui...@level2crm.com> wrote: > > > Hi Martin, > > I must say I was working with websockets yesterday. And it's delightful > experience. Have to check how it does scale but it seams just great. > > I have a doubt. Since I'm doing fully async I'm doing fully async request > with WebSocketResource. I suppose that there's no way to update the > interface from there. I mean, if we are sending a message because a model > changed on server. Can I trigger the repain of a widget? I suppose this > option is only available if using behavior right? > > > Correct! > > > > I saw the broadcast example you did. But does it worth mix WebSocketResource > and WebSocketBehavior? > > What is best, more scalable? > > 1. Doing a WebSocketResource with 1 connection that via Javascript > notifies all components in page. > 2. Use WebSocketResource + 1 WebSocketBehavior per component, and then > broadcast to all. > > Even if you have many WebSocketBehaviors in your components Wicket will > > create only one WebSocket connection per page. A web socket message sent by > the browser will be delivered to all behavior instances. You have to decide > whether the message is applicable for a given behavior or should be > discarded. > > The drawback of using WebSocketBehavior is that during the processing of a > message the Page instance will be locked, so WS messages are processed > sequencially and any Ajax requests at the same time will wait for the page > to be unlocked. > > > > > > As I told what I'm doing is a Javascript hub that receives messages (via > WebSocketResource) and sends to the widgets async so they can update. But > I suppose that following this approach it's quite difficult update > components from Javascript. And so the opposite. If a component updates > it's internal model on server, there's no way to push to the interface. > > Can I have both? The ability to update components (graphs mainly) from > javascript datasource, but from time to time, update components on wicket > and send updates to the UI (html)? > > > You can use org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster to > repaint Wicket components initiated at the server side. You will need to > preserve the page id to able to notify a specific page. Or > WebSocketBehavior should keep some extra information, e.g. userId, to > decide whether a given PushMessage is for it or not. > > > > Best regards, > > > > El 06/03/17 a las 09:08, Martin Grigorov escribió: > > Hi, > > > On Mon, Mar 6, 2017 at 3:57 AM, Gonzalo Aguilar Delgado > <gagui...@aguilardelgado.com> <gagui...@aguilardelgado.com> wrote: > > > Hello, > > I'm using the fantastic Decebals dashboard, adding a widget json > registry and some other improvements. The idea is to provide data > streaming functionality like the one provided by graphana, kibana and > friends. > > So the server will contain the datasources. And the dashboard will apply > to one or more datasources on the server. > > But I don't know what's the best way to go with wicket. > > My first idea is to provide a websocket connection with a DataManager > for each user dashboard (only 1 at a time active), subscribe to > datasources, and receive the streaming over the websockets. The > DataManager then will keep track of what topic each chart wants to > receive and multiplex the result to each chart via Javascript. > > This way there's only 1 connection to the server. But data can be shared > among widgets. I suppose it's not easy task. > > The other way is do ajax with each chart. But I think this would make a > lot of calls to the server and I suppose it's not scalable. > > Soooo. What's the best way to go?! > > > I'd use WebSockets for this! > > > > Any good chart integration on wicket apart of highcharts? D3js or > similar... > > > The demo app forhttp://wicketinaction.com/2012/07/wicket-6-native-websockets/ > uses Google > Charts library without any Wicket component integration. > > > > Preview of the current work is this link: > > https://pbs.twimg.com/media/C6M_hG6WYAEeysz.jpg > > > > -- > [image: Gonzalo Aguilar Delgado] *Level2 CRM* > Gonzalo Aguilar Delgado > Consultor CRM - Ingeniero en Informática > > M. +34 607 81 42 76 <+34%20607%2081%2042%2076> <+34%20607%2081%2042%2076> > T. +34 918 40 95 78 <+34%20918%2040%2095%2078> <+34%20918%2040%2095%2078> > E. gagui...@level2crm.com > > > > > > -- > [image: Gonzalo Aguilar Delgado] *Level2 CRM* > Gonzalo Aguilar Delgado > Consultor CRM - Ingeniero en Informática > > M. +34 607 81 42 76 <+34%20607%2081%2042%2076> > T. +34 918 40 95 78 <+34%20918%2040%2095%2078> > E. gagui...@level2crm.com > > > > >
