Hey all,

Wanted to weigh in on the subject as I have some similar feelings regarding
Wicket and since so many experienced have posted perhaps they can be

I will however include some positives. I absolutely love the idea of the
templated html page where by a web designer can build up the page and I can
focus on the back end code that adds the dynamic content. I did buy WIA and
another, Wicket Cookbook I think it is, and while I read and understand the
principals behind the framework, it was indeed a much steeper learning curve
for me. So much so that even after reading the book and starting on my own
project, I had a difficult time getting basic stuff working. However, I'd
still like to learn it more and use it for the separation it provides
between the back end and the web page itself.

I also love the idea of panels. My go to framework is (don't hate me for it)
Struts 2 and/or Jersey (via ajax calls to a rest api). I have found that I
love the idea of annotated classes to handle actions, response strings that
forward to specific jsp pages and all the code I can do.. calling to ejb
session beans, etc. The biggest down side to using Struts is, as many said,
the JSP hell. JSP itself is not too bad.. but when you add in <% %> code,
scriplets, looping constructs.. it's a darn pain in the butt to manage. This
is why Wicket appealed to me so much. Also, getting back to panels, the
notion of reusable components that you just place an element in the html
page and put the component in the tree in code and it "works" is fantastic!!
Those two things are why I will attempt to use Wicket in the near future
soon as the project I am working on is out in beta and I can look to switch
from Struts 2 to Wicket.

Now for the areas I am not so sure about and hope maybe some of you may have
some answers for.

The big one for me is the server side statefulness. Maybe I misunderstood
this, but I am really worried about the ability for Wicket to scale given
that it keeps per user object trees in memory for the page the user is on.
On the one hand, that is pretty nifty especially for the swing like event
driven approach with ajax, but where I am not sure of is with the memory
consumption used continuously on a server, it seems to me you would reduce
the number of users per server you could handle. More so, replication of
state information would require 2 (or more) servers in a cluster to have the
same sort of object tree + state in memory to have any sort of fault
tolerance. Am I correct in understanding how Wicket maintains an object tree
per user on the server side? If this is the correct understanding then to me
the stateless model of using a REST api or Struts actions where each request
comes in with a session id, and minimal data is in the session.. typically
just a userId tied to the sesion id so data can then be looked up using the
userId. Again, if I am correct, then the struts/mvc approach typically is
keep as little in memory across requests, but each request may need to spend
some processing time loading up data to reconstruct a page to send back as a
response (or set as attributes for a JSP page to use to render the response
with). So there is a bit more processing and temporary memory use, but the
memory expands/contracts continuously as users make requests and responses
go back. At least as far as  I understand the whole scalability side of
things, this is better for more user capacity. As for session replication,
at least in the old days, you had to replicate session data to at least one
other server in the cluster. In Wicket, how is this done?

Another area I am not keen with at all with wicket which is mentioned is
having to build the object tree code the same way the html page is. With
element Ids, I am a little confused as to why we cant simply insert the
component using the element id and let wicket figure out where to stick it
on the page. To me, as it scans the html page for wicket ids, it should be
able to pluck wicket component/objects from a Map using the same ID and put
it where it needs to be. This is one of the areas I have had some trouble
getting right. If Wicket did not have this requirement, you could rearrange
panels, components, etc on a page and not have to worry about any server
side code change, redeploy, etc. It would, in my opinion "fix" Wicket as the
ultimate framework (barring my question about scalability/session memory
above also being resolved). Someone mentioned Wicket 6 will resolve
something of this.. if you could elaborate (or point a link) that would be
great. I would love to see them resolve this issue in the framework. It
would be great to allow a web page designer build up the page, then I add
dynamic elements, then they decide to change things around and simply edit
the page and redeploy and see the changes, then do it again until they like

Lastly, the bookmarkable and ugly link stuff.. I also agree that it's a bit
of a pain. It may make sense to some, but having to worry about bookmarkable
links and when to use them or not, etc adds to the complexity and learning
curve. I think this is one other area I enjoy about Struts, but perhaps I've
not worked enough with Wicket to fully realize why its needed and/or can't
just be avoided.

Otherwise, I love the idea of Wicket. I've often thought of making my own
template framework like how I describe above.. stateless on the server side
(no object model in memory), modular components that can be reused on any
page, without all the JSP scriplet nightmares. 

Look forward to any replies. Thanks all.

View this message in context: 
Sent from the Users forum mailing list archive at Nabble.com.

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to