Hi, You didn't say what your web service response's type is. By referring to jQuery's #load() method it seems like your WS returns ready to render HTML, but later you say that you will create the content with pure JavaScript (JQuery) which makes me think that the returned response is plain data (JSON, XML, ...) which you will use to generate the HTML.
Wicket is (mostly) server side framework, i.e. it generates the HTML at the server and sends it to the browser for rendering. For single page applications (SPA) you start with rendering a whole Page and then by using Wicket Ajax components just need to update your components' models (pure Java code executed at the server) and Wicket will generate the HTML and send it to the browser to update the part(s) of the page. Wicket 6.0 also provides integrations with Atmosphere framework and Native WebSocket so you can use newer (HTML5) technologies for updating the view at the client side. Again you'll have to write mostly Java code to implement this. The benefit is that you can test all this very easily with unit/functional tests written in Java. If you want to use JavaScript to render the returned plain data from your web service then there is no need to include Wicket in the technology stack. But in this case you will need to use some JavaScript testing library. The JS testing libs became better last year but still not that good as Java ones. In both cases using Selenium for more complicated test scenaria will be needed. HTH martin-g On Sun, Aug 26, 2012 at 2:24 PM, seba.wag...@gmail.com <seba.wag...@gmail.com> wrote: > Hi, > > we are developers from the Apache project "Apache OpenMeetings", we > provide a Web-Conferencing application that is currently Flash-based > on the client side. > We already have a server side stack with Spring + openJPA + Axis2 that > provides us with a SOAP/REST API and ORM. > > We are currently discussing an HTML5 alternative for our Flash based > client and have to decide some basic framework questions. > Apache Wicket is one option. > > Our HTML client is likely to be a single HTML page that loads content > / components dynamically into the website. > My idea was first to use http://api.jquery.com/load/ to load > components dynamically, however maybe Wicket has a similar mechanism? > It seems like the combination of jQuery + Wicket is the most widespreaded. > But if we create our content with pure jQuery, why adding Wicket to it? > I was told that Wicket's strength is to provide a Non-JavaScript > version of the website if JavaScript is not available. However as our > basic features will be collaboration tools that really make no sense > without JavaScript, we don't need a Non-JavaScript version. > And we have already a REST interface, we don't need to duplicate one > with Wicket that provides yet another API. > > Maybe there are other arguments positive for using Wicket that I have > overseen? > > Thanks for sharing! > Sebastian > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > seba.wag...@gmail.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
