The security aspect is true. I don't see a problem in the worker
threads yet, however you might be right.

We might try a Wicket example to see how we can integrate all our
existing code into it.

Thanks!
Sebastian

2012/8/26 Martin Grigorov <mgrigo...@apache.org>:
> 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
>



-- 
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

Reply via email to