+1 for last point "Too many finals modifiers"
and subclassing isnt always better than listeners - My 2cents
Sudhir NimavatSenior software engineer.
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India
Personally I'm always ready to learn, although I do not always like being taught
________________________________
From: Ricardo Mayerhofer <ricardo.ekm.lis...@gmail.com>
To: users@wicket.apache.org
Sent: Tue, 22 December, 2009 6:49:02 PM
Subject: Wicket feedback
Hi all,
We've just finished with success a wicket project for a large online retailer.
I think wicket is the best framework out there, but as any other project there
is room for improvement. I will talk about some topics bellow, I hope it can
help in some way.
- Separation of corcerns
I think we could get a better separation of concerns if page class were focused
more in behavior and html were more focused in display (or view).
What I mean is, some times we have components that the main purpose is to add
behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping.
Take CheckGroup for exaple, it is a component focused on behavior, even though
we have to add a reference to it in HTML.
When creating composite input fields (like date), the usual way is to create a
panel even if you are not interested in reusability. A interesting aproach is
to insert a hidden text field in HTML mapped to a component that controls other
components input. It makes easier to integrate with designer and to preview in
browser. If we didn't have this limitation the hidden input would not be
necessary and the development of behavior focused components would be easier.
One thing that bothers me is when our designer move things around in HTML and
we get "added a component in code but forgot to reference it in the markup"
error, because of component hierarchy. Html tags position is a view problem not
a behavior problem, so why bother in java?
Another issue, is when we want to change the class of a div, for example, and
have to change our whole page hierarchy in java, just to manipulate that tag.
So I think a hierarchy more focused on components behavior (for example taking
care of inherited models and inputs), rather than tags position in HTML would
be better. This would make wicket more flexible and easier to work with.
- Too many finals modifiers
It's hard for a API or framework designer to foresee all uses and unxepected
situations its users may face in day to day development. Final modifiers places
a additional challenge when facing these situations. In project were deadlines
are in place, there is little room for submiting a request and waiting for a
new version to be released. Furthermore, unfortunately, it's not possible to
mock final methods making it harder sometimes to test wicket related
classes/components. What we had to do internally, is to have our own version of
wicket, mainly to remove final modifiers when necessary, a clear violation of
open/closed principle.
- Ajax
Wicket offers no stateless ajax and often changes HTML id, which makes harder
to integrate with a 3rd party ajax framework. Is there any hope for constructor
change?
Please let me know your thoughts, keep up the good work.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
http://in.yahoo.com/
