You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by "seba.wagner@gmail.com" <se...@gmail.com> on 2012/08/26 13:24:23 UTC
Deciding on frameworks - What has Wicket to offer for a Collaboration project?
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.wagner@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Ah okay,
that seems to be a misunderstanding. The velocity servlet would never
trigger the REST interface using some Java library.
The velocity servlet can access all required data that it needs to
render the HTML websites.
It would actually even use the same Spring injected Services to
trigger DB relevant queries.
Rest and velocity servlet would be invoked only from the client side.
I don't think the number of requests from the client to the server
will differ no matter if we choose the one or the other solution so
there should be no different in the number of Threads compared to
using Wicket.
But it could be true that Wicket already includes some more advanced
methods to manage those requests and threads.
We will try out using Wicket 6.x.x. I guess there is reasonable
evidence to have some standard web-app framework functionality in our
stack.
Sebastian
2012/8/26 Martin Grigorov <mg...@apache.org>:
> Thread starvation problem:
>
> 1) the Velocity servlet is deployed at /velocity
> 2) the REST API is in another app deployed at /rest
> 3) the JS client makes a call to /velocity - this acquires one worker thread
> 4) the Velocity servlet by using some HTTP client Java library makes a
> call to /rest - this acquires a second worker thread
> So now we have one request from the end user (the JS call) but it
> needs two worker threads to do the job. When the REST call returns it
> releases the second thread and then the velocity request is processed
> and releases the first acquired thread. This is the starvation part.
>
> The deadlock case: let's say your worker thread pool has MAX value -
> 100 threads. This means that if you have 100 simultaneous requests
> from the JS clients you will acquire all the 100 worker threads at
> once. In this corner case none of these threads could make its call to
> the REST API because there is no free worker thread to process it, so
> all 100 will hang waiting for resources/threads.
>
> In Tomcat thread pools are per HTTPConnector so you can "solve" this
> problem by making the calls to the REST APIs on a second http port
> (second http connector) but this will mean that you have to configure Tomcat
> before deploying the app and use some kind of firewall to hide the REST APIs
> from end clients (JS ones). If this additional admin setup is OK for
> your app then it will work.
>
> I'm not trying to convince you to use Wicket. The same problem is
> valid if your Wicket code makes these additional http requests to the
> REST APIs.
>
> In any case, I'll be glad to know which direction you and your
> colleagues at OpenMeetings will choose.
>
> On Sun, Aug 26, 2012 at 8:12 PM, seba.wagner@gmail.com
> <se...@gmail.com> wrote:
>> 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 <mg...@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.wagner@gmail.com
>>> <se...@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 <mg...@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.wagner@gmail.com
>>>>> <se...@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.wagner@gmail.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Martin Grigorov
>>>>> jWeekend
>>>>> Training, Consulting, Development
>>>>> http://jWeekend.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Ah okay,
that seems to be a misunderstanding. The velocity servlet would never
trigger the REST interface using some Java library.
The velocity servlet can access all required data that it needs to
render the HTML websites.
It would actually even use the same Spring injected Services to
trigger DB relevant queries.
Rest and velocity servlet would be invoked only from the client side.
I don't think the number of requests from the client to the server
will differ no matter if we choose the one or the other solution so
there should be no different in the number of Threads compared to
using Wicket.
But it could be true that Wicket already includes some more advanced
methods to manage those requests and threads.
We will try out using Wicket 6.x.x. I guess there is reasonable
evidence to have some standard web-app framework functionality in our
stack.
Sebastian
2012/8/26 Martin Grigorov <mg...@apache.org>:
> Thread starvation problem:
>
> 1) the Velocity servlet is deployed at /velocity
> 2) the REST API is in another app deployed at /rest
> 3) the JS client makes a call to /velocity - this acquires one worker thread
> 4) the Velocity servlet by using some HTTP client Java library makes a
> call to /rest - this acquires a second worker thread
> So now we have one request from the end user (the JS call) but it
> needs two worker threads to do the job. When the REST call returns it
> releases the second thread and then the velocity request is processed
> and releases the first acquired thread. This is the starvation part.
>
> The deadlock case: let's say your worker thread pool has MAX value -
> 100 threads. This means that if you have 100 simultaneous requests
> from the JS clients you will acquire all the 100 worker threads at
> once. In this corner case none of these threads could make its call to
> the REST API because there is no free worker thread to process it, so
> all 100 will hang waiting for resources/threads.
>
> In Tomcat thread pools are per HTTPConnector so you can "solve" this
> problem by making the calls to the REST APIs on a second http port
> (second http connector) but this will mean that you have to configure Tomcat
> before deploying the app and use some kind of firewall to hide the REST APIs
> from end clients (JS ones). If this additional admin setup is OK for
> your app then it will work.
>
> I'm not trying to convince you to use Wicket. The same problem is
> valid if your Wicket code makes these additional http requests to the
> REST APIs.
>
> In any case, I'll be glad to know which direction you and your
> colleagues at OpenMeetings will choose.
>
> On Sun, Aug 26, 2012 at 8:12 PM, seba.wagner@gmail.com
> <se...@gmail.com> wrote:
>> 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 <mg...@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.wagner@gmail.com
>>> <se...@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 <mg...@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.wagner@gmail.com
>>>>> <se...@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.wagner@gmail.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Martin Grigorov
>>>>> jWeekend
>>>>> Training, Consulting, Development
>>>>> http://jWeekend.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by Martin Grigorov <mg...@apache.org>.
Thread starvation problem:
1) the Velocity servlet is deployed at /velocity
2) the REST API is in another app deployed at /rest
3) the JS client makes a call to /velocity - this acquires one worker thread
4) the Velocity servlet by using some HTTP client Java library makes a
call to /rest - this acquires a second worker thread
So now we have one request from the end user (the JS call) but it
needs two worker threads to do the job. When the REST call returns it
releases the second thread and then the velocity request is processed
and releases the first acquired thread. This is the starvation part.
The deadlock case: let's say your worker thread pool has MAX value -
100 threads. This means that if you have 100 simultaneous requests
from the JS clients you will acquire all the 100 worker threads at
once. In this corner case none of these threads could make its call to
the REST API because there is no free worker thread to process it, so
all 100 will hang waiting for resources/threads.
In Tomcat thread pools are per HTTPConnector so you can "solve" this
problem by making the calls to the REST APIs on a second http port
(second http connector) but this will mean that you have to configure Tomcat
before deploying the app and use some kind of firewall to hide the REST APIs
from end clients (JS ones). If this additional admin setup is OK for
your app then it will work.
I'm not trying to convince you to use Wicket. The same problem is
valid if your Wicket code makes these additional http requests to the
REST APIs.
In any case, I'll be glad to know which direction you and your
colleagues at OpenMeetings will choose.
On Sun, Aug 26, 2012 at 8:12 PM, seba.wagner@gmail.com
<se...@gmail.com> wrote:
> 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 <mg...@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.wagner@gmail.com
>> <se...@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 <mg...@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.wagner@gmail.com
>>>> <se...@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.wagner@gmail.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by Martin Grigorov <mg...@apache.org>.
Thread starvation problem:
1) the Velocity servlet is deployed at /velocity
2) the REST API is in another app deployed at /rest
3) the JS client makes a call to /velocity - this acquires one worker thread
4) the Velocity servlet by using some HTTP client Java library makes a
call to /rest - this acquires a second worker thread
So now we have one request from the end user (the JS call) but it
needs two worker threads to do the job. When the REST call returns it
releases the second thread and then the velocity request is processed
and releases the first acquired thread. This is the starvation part.
The deadlock case: let's say your worker thread pool has MAX value -
100 threads. This means that if you have 100 simultaneous requests
from the JS clients you will acquire all the 100 worker threads at
once. In this corner case none of these threads could make its call to
the REST API because there is no free worker thread to process it, so
all 100 will hang waiting for resources/threads.
In Tomcat thread pools are per HTTPConnector so you can "solve" this
problem by making the calls to the REST APIs on a second http port
(second http connector) but this will mean that you have to configure Tomcat
before deploying the app and use some kind of firewall to hide the REST APIs
from end clients (JS ones). If this additional admin setup is OK for
your app then it will work.
I'm not trying to convince you to use Wicket. The same problem is
valid if your Wicket code makes these additional http requests to the
REST APIs.
In any case, I'll be glad to know which direction you and your
colleagues at OpenMeetings will choose.
On Sun, Aug 26, 2012 at 8:12 PM, seba.wagner@gmail.com
<se...@gmail.com> wrote:
> 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 <mg...@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.wagner@gmail.com
>> <se...@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 <mg...@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.wagner@gmail.com
>>>> <se...@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.wagner@gmail.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <mg...@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.wagner@gmail.com
> <se...@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 <mg...@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.wagner@gmail.com
>>> <se...@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.wagner@gmail.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <mg...@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.wagner@gmail.com
> <se...@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 <mg...@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.wagner@gmail.com
>>> <se...@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.wagner@gmail.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by Martin Grigorov <mg...@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.wagner@gmail.com
<se...@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 <mg...@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.wagner@gmail.com
>> <se...@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.wagner@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by Martin Grigorov <mg...@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.wagner@gmail.com
<se...@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 <mg...@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.wagner@gmail.com
>> <se...@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.wagner@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <mg...@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.wagner@gmail.com
> <se...@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.wagner@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <mg...@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.wagner@gmail.com
> <se...@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.wagner@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Deciding on frameworks - What has Wicket to offer for a
Collaboration project?
Posted by Martin Grigorov <mg...@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.wagner@gmail.com
<se...@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.wagner@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org