Thanks for the detailed answer Martin! You are right in my description I missed one part, for generating the HTML my plan was to use Apache Velocity. The REST interface will only generate data to fill that HTML.
I've created a MockUp of the architecture proposal that should cover it all: https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal Wicket seems to be more likely to be a classic web-application-framework. From my point of view we are more looking for a UI framework. Thanks! Sebastian 2012/8/26 Martin Grigorov <mgrigo...@apache.org>: > 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 > -- 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
