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
