On 4/4/07, Neeme Praks <[EMAIL PROTECTED]> wrote:
Matej Knopp wrote: > But wicket is a framework that manages server side state. That is quite a strong statement and I do not see it backed up by "official" Wicket "marketing story". http://incubator.apache.org/wicket/introduction.html Wicket is all about writing modular web applications in java, with all the benefits that come with the strongly-typed language. The word "server" is rarely mentioned in the documentation and "server side state" is an implementation detail.
True that it might not be that clear from the docs, but one of Wicket's main goals is to enable true (unmanaged) object oriented programming in the web tier. State management follows from that, as encapsulation is one of the central ideas in OO.
If we can write modular web applications in java and publish parts of them as JavaScript to be run in the client, thus reducing the amount of server state - I think this is still Wicket.
It depends on how far it goes. Take GWT. It is great in certain aspects and potentially certainly super scalable. Otoh, Wicket due to it's 'server orientation' is much stronger when it comes to taking advantage of locality and interacting with the business tier in an unrestricted fashion (though you have to be aware of what ends up being in memory over requests). A good example of this is when you work with objects that are mapped by ORM like Hibernate/ EJB 3 and/ or objects that use services that can't easily be translated to a JavaScript counterpart. What I can imagine is that there are a couple of optimizations possible that will allow for a model closer to GWT. However, my main fear would be - besides the fact that we cannot have much more on our place currently as we're all too busy - that it could result in a sloppier programming model (too many ways to achieve the same thing). Anyway, a prototype certainly would be great stuff to have for a discussion, so Neeme, if you have something concrete, that would be awesome. Eelco
