What I really like about Wicket is that it -- much more than JSPs --
allows the separation of HTML markup from Java code. No "c:if"ing with a
Domain Specific Language like JTSL (or Velocity macros) inside HTML
markup and side-by-side with javascript. In Wicket, in contrast, HTML
markup contains only HTML and Wicket tags, which look just like
HTML tags. That's it.
But I think this could be taken a bit farther, and I'd like the list's
thoughts on a proposal.
Wicket imposes one constraint on markup: roughly, any HTML element with
a "wicket:id" attribute must match a Wicket Component, a Java Object, in
the Java code. More precisely, the HTML element tree (considering only
"wicket:id" elements) must (with a few exceptions) match the Wicket
Component tree rooted at the Wicket Page.
But -- in my opinion -- Wicket goes a bit too far in enforcing this. In
particular, there are at least three ways to allow a web page user to
select one thing from a list of several things:
A drop down list, like this:
<select><option>one</option><option>two</option></select>
A list that scrolls but doesn't drop down, as above but with the
select tag given a "size" attribute.
Or, a group of radio buttons, like this:
<input type=radio>one</input><input type=radio>two</input>
To the application and its programmer, these are all the same
functionality: present some choices, find out which SINGLE choice the
user selects. How that looks on the page is immaterial to the
application's functionality.
To the page designer, these are all different, presenting different
looks, talking up different amounts of screen space, each with a
slightly different learning curve for the user. In particular, novice
web users may not even realize the drop down is a choice and can be
clicked on, dropped down, and changed.
If the page designer decides that, say, he's dealing with a less
web-savvy population, and wants to change the dropdown to a group of
radio buttons, someone has to send a change request to the Java programmer.
Then the programmer has to change some or all instances of one class
derived from AbstractSingleSelectChoice (e.g., DropDownChoice) to
another (e.g., RadioChoice). Which shouldn't happen; the way the choice
is rendered has nothing to do with the the page's functionality.
In Model-View-Controller terms, the rendered look is purely up to the
Model; the functionality purely the domain of the Controller.
Would it be useful to have a Wicket Component that automatically
rendered whichever type look the page designer wants, further decoupling
web page designer's View from Programmer's Controller, while
providing a single uniform functional interface to the application?
Thanks or reading, and I hope to hear your feedback.
--Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
