On 3/1/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > Interesting, I didn't know it was possible to ask the component tree > > which components wants to rerender. This could indeed answer to my > > first point. But if I want finer grain component update (for > > > I build this my self. I know because of our design when components gets > new state or new data pushed. (our models do have things like Swing event > listeners)
Ok, I get it better now. And is it something that could be shared with the community? > > > > repeaters), I guess the implementation would be a little bit more > > complex: the repeating component would have to say "I want to > > rerender, but only partially". Note that it would make it very easy > > If the repeater component itself doesn't say it wants to rerender (because > its model changed) > but a component in the repeater component says it because his model did > change > then i have partial repeater updates just fine. Yes, this is fine, but if you insert a new item in a list, you will need to rerender the whole list. And in some situations it may be a problem. Do you imagine in a chat application do rerender the whole chat history each time someone speak? > > > > for wicket users to get an automatic refresh with fine grain: add an > > instance of a behavior similar to the one you use now (which could be > > part of wicket or wicket contrib, since it seems very generic), and > > that's all. Then all you have to do is update your models, and they > > will "magically" be updated on the client, with a limiting transport > > when you insert a new sub component in a repeating view. Very nice. > > It will be a bit hard for this to do in the standard wicket, because data is > pulled > not pushed. I only know it because data is pushed to the wicket models > and because i register the push (set a flag is changed) i know the next time > i have a rendering phase the component renders it self again. Yes, this wouldn't be really standard wicket. I would need a way to know that only one item has been added, and a way to render only that line and send this to the client. But I think it's possible, at least by subclassing the repeating views I wanna use, or patching wicket. > > ofcourse if cometd really would work that i could ask the container at some > point > for a connection again. Then i don't have to wait for the client timer event > but could push it directly. AFAIK cometd gives the illusion that you can ask for a connection from the server, but under the hood it's still polling. But polling with long running connections and a server side which know how to deal with it, so it's certainly better that basic polling. That's why I'd like to take advantage of that to provide instant feedback to the client. > > > > But it's still opaque for me how the component know it has to be > > refreshed. Indeed I'm surprised to see that the IModel interface > > provides no way to get "observed" for changes. In a rich client > > framework you always have such facility, which makes possible for a > > component to know that its model has changed. And web 2.0 gets closer > > and closer to the rich client world, so maybe this is something that > > could be considered in wicket? > > This is because of the rendering nature of the browser. (real pushing is > still > not really standard thing) But you could design it the way you like: > > component->wicketmodel with event listener->your real datamodel. Yes, but is there a "wicketmodel with event listener", or do I have to define my own? And if I define my own, I guess I'll have either to use my own components too so that they listen to the changes, or use another class to do the binding. Moreover, the more I think about it, the more I think it's not really suitable for the web. Since no real push is possible, I think it's better to keep control over the batch of rendering events sent to the client. To be sure two related components updates are not split in two separate HTTP responses. But maybe this could be achieved in another way than the one I was proposing first: when you want to group several updates together, you could call a method on the page to say "I begin to make changes I want to group", and then call another method at the end to say "I've finished, you can push my changes now". This way trivial changes would be as easy as they should be (the model change triggers the rendering event) or grouped as you want. Could be nice. So I think I'll try to begin playing with Vincent cometd prototype, and start some basic POC on my own to see how things are going. And I'll give you feedback from my experience here. Thanks a lot to all of you for sharing your ideas and experience! - Xavier > > > johan > > > ------------------------------------------------------------------------- > 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
