As gerald mentioned address the content - not the speaker, much more

i'll address a few of your points and bring up a few of my own.  I'm sure
the others can be addressed with thoughtful/intelligent responses.

*Violates DRY*:  There is a reason that HTML is separated from your
corresponding Java component (not every html snippet has to have a component
btw).  Behavior is not allowed in your HTML and that makes me happy.  I can
have a Human Factors/Web designer do what they do best.  Design a beautiful,
high fidelity prototype that has taken actual user need in mind with plain

I've seen data driven UI's done by backend programmers - not so nice. I know
because I've done them myself.

Not having behavior embedded in your view like a JSP/Facelet means that when
something goes wrong with a page, I have one place to look - in the
corresponding Java component.  No hidden loops tucked away in that page, no
calls to a Java API embedded within a mess of HTML code - clean separation.

*Breaks POJOS*:  The data being stored in your model doesn't have to
implement an interface.  See this response

A couple of things I think Wicket could improve upon is when you *don't*
want back button support and having to worry about PageMaps being stored in
the users session & disk.  As this is a corner case for the most part in the
web app world, I can live with what I have.

In that same vein, having to deal with PageExpiration exceptions when back
button support is not needed and I don't want my users to encounter this
when an Ajax action takes place.  Again this is not the norm and there's a
workaround but it's hacky.

As mentioned no UI framework is perfect.  All have their strengths and
weaknesses and usually those depend on your point of view, coding style,
time of day...

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

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to