> Obviously lots of pros and cons for both that have not been mentioned so
> far.
Yup, lots of those. Another one is that GWT works with layout managers
and Wicket directly with HTML. Anyway, I think there are other threads
in the archives that do a more complete comparison.
Eelco
--
Is the browser not a client in Wicket? You have to slice things differently.
I agree that using GWT will mean more thought has to go into interaction
with the middle tier but that just means some of your code stays on the
server in some simple facade. It wouldn't be one of my worries in using GW
how about another tiny limitation which is the programming model. gwt is
essentially client+server so you cannot use hibernate lazy loading, you
cannot use data locality to your advantage either. you have to serialize all
your data so you can only use simple objects to communicate between your
serv
Another big GWT limitation is that you have a very small subset of java
runtime to write your UI in. Lots of your favourite things are probably
missing.
--
View this message in context:
http://www.nabble.com/Questions-about-GWT%2C-JSF-and-Wicket-tf4514338.html#a12879789
Sent from the Wicket - Us
One of the requirements here is to support old browsers and browsers with JS
disabled...
I'd have liked to have a go at using the gwt html project even though it is
very, very new but that was seen as way too scary.
John Krasnay wrote:
>
> On Tue, Sep 25, 2007 at 03:07:21AM -0700, Sam Hough
On Tue, Sep 25, 2007 at 03:07:21AM -0700, Sam Hough wrote:
>
> Taking as a basic assumption that the reason we want GWT or Wicket is to do
> almost all our logic in Java and Wicket is in full Ajax mode:
>
> 1) In GWT a lot of the UI logic can be moved to the client. e.g. If a user
> changes focus
Taking as a basic assumption that the reason we want GWT or Wicket is to do
almost all our logic in Java and Wicket is in full Ajax mode:
1) In GWT a lot of the UI logic can be moved to the client. e.g. If a user
changes focus GWT can call event handlers, authored in Java, that update the
UI with
On 9/25/07, Sam Hough <[EMAIL PROTECTED]> wrote:
> You will get a much more responsive application with GWT than you will ever
> get with
> Wicket.
Care to elaborate on that please? As far as I know, GWT uses HTTP,
just as Wicket. I *REALLY* don't see how that gives GWT an advantage
in responsive
I wouldn't go for Wicket _and_ GWT. The server side could stay the same with
GWT. The big change would be that GWT would make remote calls to it...
If you need to support low end browsers then go for Wicket. If you don't go
for GWT.
Apart from no-javascript support the only other big problem is
Hi,
A list of url, that could help you...
About Wicket vs JSF, there is some articles :
* http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/ (from the
author of JTrac)
* a list of articles : http://cwiki.apache.org/WICKET/articles-about-wicket.html
About widgets :
* take a look
Hello,
at the moment I'm writing my diploma-thesis. The project I'm working
on is for a big company in germany and consists of porting a
Rich-Client-Java-Application to a web-based Application. It should
make heavy use of AJAX-Components, because it should behave like the
Rich-Client. If the exper
11 matches
Mail list logo
