Hi Sebastian, I see a little problem in your architecture - the jQuery client will make a request to the Velocity servlet, then if you use the REST API you'll need to make another http request. If both the servlet app and the REST app are deployed on the same web container instance/node then you will face thread starvation problem for http worker threads, possible deadlock too. So you may need to deploy the different parts on different nodes.
Also think early how you will implement the security part of the application. Sometimes classics are much easier ;-) On Sun, Aug 26, 2012 at 5:36 PM, seba.wag...@gmail.com <seba.wag...@gmail.com> wrote: > 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 > -- 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
