>From my own experience with Wicket Ajax, and I have been working quite a lot with it lately to implement a drag and drop portal similar to igoogle, the biggest issue for me is back button support. I have seen a ticket created for it in JIRA, but not sure if this is still planned for 1.5.
Other than that, I actually quite like how ajax currently works in wicket via the use of behaviors. I haven't found a use case so far that I wasn't able to solve. Without back button support or a way to manage history, implementing a single page type of application becomes a bit difficult to do in wicket. Refreshing the page via F5 should also obviously show the current state of the page and not re-instantiate it from scratch. -hc Martin Funk-3 wrote: > > Hi Matej, hi list, > > I just saw the page that Matej added to the wiki, so I thought it might > be wishing time for improving Wicket Ajax now. > > My wishes are somewhat vague, but I just don't wanna miss the wishing > window :-) > > Sven and I have been happily coding on wicket-contrib-gmap2, which also > shows just about our level of understanding the wicket and ajax space. > At least mine, Sven is probably fare ahead of me. > > So coding on that, I came to think, if we have a chance to get something > like a JavaScriptComponent with the following capabilities: > > It should be addable to a component, just like a component. > It should be addable to other JavaScriptComponents. > It should not need any markup. > It should carry its own session unique id. > It should have its own callbackurl > Adding it should result in an instantiation of a JavaScript object on > the browser side. > This JavaScript object should have the capabilities of sending a basic > XMLHttpRequest to its corresponding java-object using the callbackurl. > Adding or removing either one of them should result with the same effect > to the other. > > I'm not quite sure if this draws the picture I'm thinking of, or if > asking this is getting to carried away from wicket and introduces > complexity that can't be handled. Though I have the feeling wicket is > not to far away from it anyway. > To me it looks like mixing capabilities of component with capabilities > of AbstractAjaxBehavior. > Sorta make em AjaxBehaviors full members of the component hierarchy and > loosen on Components need for markup. > OK the infrastructural JavaScript object providing the basic protocol > between the two halves of the object does not exist yet. > > But if that could be accomplished quite a door could be opened (or the > box of Pandora) > Subclassing JavaScriptComponent wouldn't be trivial as you'd have to > come up with JavaScript code too. > Though this would lay a good basis for handling the js-object on the > browser communication to the server side. So you would not only be able > to add the nice goodies to the browser but also get a basis for letting > the server know of any events on the browser. > > Any other thoughts on this? > > Martin > > > > BTW. there is still an issue on behaviors open > https://issues.apache.org/jira/browse/WICKET-713 > > > > -- View this message in context: http://www.nabble.com/Wicket-1.5-Ajax-tp19189204p19214000.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
