Re: Submitting a DateTextField value in a different timezone that the browser
Thanks François
2013/8/3 Francois Meillet francois.meil...@gmail.com
Overriding the getClientTimeZone() method in the dateconverter sounds good.
if the boolean applyTimeZoneDifference of the dateConverter is set to true.
add(new DateTextField(xxx, new DateConverter(true) {
@Override
public String getDatePattern(Locale locale) {
// ...
}
@Override
protected DateTimeFormatter getFormat(Locale locale) {
// ...
}
protected TimeZone getClientTimeZone() {
return yourspecifictimezone;
}
}));
François
Le 3 août 2013 à 02:38, seba.wag...@gmail.com a écrit :
Hi,
According to:
http://ci.apache.org/projects/wicket/apidocs/6.0.x/org/apache/wicket/datetime/markup/html/form/DateTextField.html
*This component tries to apply the time zone difference between the
client
and server. See the date
converter
http://ci.apache.org/projects/wicket/apidocs/6.0.x/org/apache/wicket/datetime/DateConverter.html#getApplyTimeZoneDifference%28%29
of
this package for more information on that.*
In our application users can configure the timezone of the UI different
from the browser/client/os timezone.
Apart from the reasons when and how and why we are doing that ...
Is there a way to configure the DateTextField to use a different timezone
then the clients/browser/os one for its calculations?
My basic idea is to overwrite the method getClientTimeZone in the
DateTimeField.
I wonder if that is the appropriate way to do it?
Are there other ideas or pointers how to resolve that?
Thanks,
Sebastian
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
Submitting a DateTextField value in a different timezone that the browser
Hi, According to: http://ci.apache.org/projects/wicket/apidocs/6.0.x/org/apache/wicket/datetime/markup/html/form/DateTextField.html *This component tries to apply the time zone difference between the client and server. See the date converterhttp://ci.apache.org/projects/wicket/apidocs/6.0.x/org/apache/wicket/datetime/DateConverter.html#getApplyTimeZoneDifference%28%29of this package for more information on that.* In our application users can configure the timezone of the UI different from the browser/client/os timezone. Apart from the reasons when and how and why we are doing that ... Is there a way to configure the DateTextField to use a different timezone then the clients/browser/os one for its calculations? My basic idea is to overwrite the method getClientTimeZone in the DateTimeField. I wonder if that is the appropriate way to do it? Are there other ideas or pointers how to resolve that? Thanks, Sebastian -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
Why is it forbidden to overwrite getString method in the Component class ?
Hi, I am wondering why it is forbidden to overwrite public final String getString(final String key) in org.apache.wicket.Component ? What is the reason of forbidding anybody to use his custom resource loading mechanism ? Thanks! Sebastian -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
Re: Why is it forbidden to overwrite getString method in the Component class ?
Thanks Martin, using IStringResourceLoader solved my issue. However I did not understand what you meant with #getMyString() I did not find any method #getMyString() that I could overwrite, also Google gave me no pointers where this function is hidden. Did you meant to overwrite the getString method in the Localizer? Thanks! Sebastian 2012/10/23 Martin Grigorov mgrigo...@apache.org Hi, You can always use #getMyString() for custom loading. Or you may just need to add an additional/custom IStringResourceLoader instead of overriding #getString(). On Tue, Oct 23, 2012 at 3:56 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: Hi, I am wondering why it is forbidden to overwrite public final String getString(final String key) in org.apache.wicket.Component ? What is the reason of forbidding anybody to use his custom resource loading mechanism ? Thanks! Sebastian -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com -- 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
Re: issue with file download out of form component
Hi Martin, thanks for committing a patch that fast! I see your patch at: http://markmail.org/message/ntjpnxce6uw44ejt But I don't know what SNAPSHOTs are compiled from that one. Will this fix be in the next 6.2.0-SNAPSHOT or 6.0.0-SNAPSHOT ? We sync our dependencies from: https://repository.apache.org/content/groups/snapshots/org/apache/wicket/wicket/ Where is your Thanks! Sebastian 2012/10/17 Martin Grigorov mgrigo...@apache.org There was a response from Maxim from OpenMeetings team, but users@wicket.apache.org was not in CC: copy Hello Martin, I have modified the code and have removed AjaxDownloader (since it is not really necessary). NullPointerException somehow happens while post parameters parsing (getCallbackURL) is not working anymore. I believe this is somehow connected with custom HomePageMapper https://svn.apache.org/viewvc/incubator/openmeetings/trunk/singlewebapp/src/org/apache/openmeetings/web/app/Application.java?revision=1384647view=markup line 62 and below. Maybe you can help me with this? I have added HomePageMapper to implement single page application and remove all URL parameters automaticatilly being added by Wicket. Thanks in advance /copy Hi Maxim, The NullPointerException is while Wicket tries to read the POST parameters. The request mappers manipulate only the GET parameters, so I think it is not related. I've just checked Jetty 7.6.3 sources and they return String[0] so it should be OK in this particular version of Jetty. But I'll add the check anyway with https://issues.apache.org/jira/browse/WICKET-4818 On Wed, Oct 17, 2012 at 9:16 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Tue, Oct 16, 2012 at 7:59 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: Hi, I did follow this tutorial to create a download via Ajax in a form: https://cwiki.apache.org/confluence/display/WICKET/AJAX+update+and+file+download+in+one+blow The slightly modified code can be seen here: https://svn.apache.org/viewvc/incubator/openmeetings/trunk/singlewebapp/src/org/apache/openmeetings/web/components/admin/backup/BackupPanel.java?view=markup Line 127 download.initialize(target); is called. It seems you have modified BackupPanel. There is no code like download.initialize(target) The rest seems to me similar to the example, except for that I set the File is set dynamically with every Ajax request. The File itself does exist and is created correctly. However Wicket throws this wired exception: http://pastebin.com/raw.php?i=Fijqjd5y NullPointerException is not something one should expect so it is a bug. According to https://github.com/apache/wicket/blob/build/wicket-6.0.0/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java#L321 its cause is that HttpServletRequest.getParametersMap() returns a Map with an entry with value == null. I'm not sure in what cases this can happen but I'll add a check for null there. The trace seems to be an internal Wicket error. Is this a Bug inside Wicket? Sebastian -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- 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
Re: JavaScript execution on Ajax response in Wicket
Thanks Sebastian,
I was able to resolve it based on your examples!
Sebastian
2012/9/16 Sebastien seb...@gmail.com:
Hi Sebastian
The issue is that $(document).ready( function() is not called (or only
the first time) a Panel is loaded via Ajax.
IMHO, the main thing to understand while working with jQuery is that, when
you re-attach your component, you need to re-execute the jQuery statement.
A generic way to achieve this is to add (jQuery)behavior added to your
component.
In behavior#renderHead()):
AjaxRequestTarget target =
component.getRequestCycle().find(AjaxRequestTarget.class);
if (target != null)
{
target.appendJavaScript(this.$());
}
else
{
response.render(JavaScriptHeaderItem.forScript(this.$(), this.getToken()));
}
where #$() gets the jQuery statement.
Additionally to the load of the Ajax Panel, we need to trigger an
JavaScript event every time the table dynamically loads new records to the
grid/table.
You can achieve this in the same way as describe above, by attaching the
statement you want to be executed.
Feel free to have a look to the code severals jQuery / Wicket integrations
did. For instance, the base JQueryAbstractBehavior of wicket-jquery-ui
could be found here:
https://github.com/sebfz1/wicket-jquery-ui/blob/wicket6/wicket-jquery-ui-core/src/main/java/com/googlecode/wicket/jquery/ui/JQueryAbstractBehavior.java
Also, these integrations are designed to be extended and already solve
these kind of issues...
Best regards,
Sebastien.
On Sun, Sep 16, 2012 at 10:25 AM, seba.wag...@gmail.com
seba.wag...@gmail.com wrote:
Hi,
we build a single page application and want to extend that with some
jQuery plugins.
The issue is that $(document).ready( function() is not called (or
only the first time) a Panel is loaded via Ajax.
Example1 JavaScript in HTML wicket:head:
https://svn.apache.org/viewvc/incubator/openmeetings/trunk/singlewebapp/src/org/apache/openmeetings/web/components/admin/configurations/ConfigsPanel.html?view=markup
Line 27ff
= Works, but only one time: The first time you initialize the Panel,
$(document).ready is executed, the second time you click on the menu
item / load the Panel via Ajax,the JavaScript is not executed
Example2 JavaScript pragmatically injected by overwriting
renderHead(HtmlHeaderContainer container):
https://svn.apache.org/viewvc/incubator/openmeetings/trunk/singlewebapp/src/org/apache/openmeetings/web/components/admin/configurations/ConfigsPanel.java?view=markup
Line 45ff
= Works but $(document).ready is executed before the table with the
id example is rendered in the UI, so you can't see any effect
Additionally to the load of the Ajax Panel, we need to trigger an
JavaScript event every time the table dynamically loads new records to
the grid/table.
From examples in the Net I can ready that AjaxRequestTarget is used
for that. However the Panel itself does not provide a method to
overwrite or similar to catch such events globally for a the
component.
I guess this is a common issue in Wicket, how do folks solve it?
Thanks!
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
--
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
what license is WicketStuff DataTables ?
I was wondering what license: https://github.com/wicketstuff/core/wiki/DataTables is. I could not find any information on the licenses of that product and if it is compatible with Wicket 6.0.0. Does anybody know something about that? Thanks! 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
Setup Wicket in Eclipse without need to re-initialize the whole servlet container
Hi, we have set up Wicket in OpenMeetings and it is working fine! However the development cycle is pretty long: Every change requires us to recompile and restart the servlet container. As we use Wicket + Spring + openJPA a restart takes around 20 seconds + compilations time, it takes around 30 seconds in total. When working with UI components you regularly sit on your desk and wait for this cycle to complete ;) Is there a way to develop and test Wicket more agile? Is there some Hot-plug mechanism that does not require to reload the whole servlet container with every change? Thanks! 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
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.wag...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Deciding on frameworks - What has Wicket to offer for a Collaboration project?
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
Re: Deciding on frameworks - What has Wicket to offer for a Collaboration project?
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
Re: Deciding on frameworks - What has Wicket to offer for a Collaboration project?
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 mgrigo...@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.wag...@gmail.com seba.wag...@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 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
