On Fri, Jul 11, 2014 at 1:31 AM, Garret Wilson <gar...@globalmentor.com> wrote:
> Everyone, > > Wicket was created in a world in which little was done at display time to > manipulate the HTML DOM tree, so Wicket felt like it had free reign to muck > around with the HTML given by the developer. But in today's world in which > we use JavaScript libraries like jQuery to modify the DOM on a whim, and > CSS libraries such as Yahoo! Pure to provide styling, Wicket's modification > of the HTML I give it can wreak havoc with my application. > > 1. Let me give you two examples. The first is BookmarkablePageLink. I have > a simple and semantically useful navigation: > > <nav> > <ul> > <li><a wicket:id="homePageLink" ... > > I throw in a couple of CSS classes from Yahoo! Pure CSS Library, and it > turns into a beautiful menu with mouseover highlighting, selected items, > etc. I use a BookmarkablePageLink to wrap each link. But some menu items > are only available to users with certain permissions, so I want to disable > some of them. Oops! When I call BookmarkablePageLink.setEnabled(false), > the HTML changes! Suddenly my <a> tags are turned into ugly <span><em> > tags, completely destroying the look of the menu because Yahoo! Pure CSS > doesn't recognize <span><em> tags as menu items. > > Sure, I can call getMarkupSettings().setDefaultBeforeDisabledLink(...) > and friends, but I shouldn't have to. This is a holdover from the days when > stylistic changes were made by changing the HTML, not by applying CSS. I > recommend that by default links should not change the HTML, but instead add > or remove a particular HTML class value. > > 2. The second example is CheckBoxMultipleChoice. I have a nice set up > checkboxes in the HTML: > > <div wicket:id="widgets"> > <label for="foo"><input id="foo" type="checkbox"/> Foo</label> > <label for="bar"><input id="bar" type="checkbox"/> Bar</label> > </div> > Created https://issues.apache.org/jira/browse/WICKET-5640 for p.2 Please comment in the ticket with suggestions what and how to improve. > > Without Wicket, those look nice; they are displayed horizontally, and the > labels are beside the checkboxes: > > X Foo X Bar > > But if I use CheckBoxMultipleChoice, it completely screws up the HTML! > Suddenly my HTML looks like this: > > ...<input .../><label ...>foo</label><br/><input .../><label > ...>bar</label><br/> > > Wicket has not only taken my <input> out of the <label>...</label>, it has > added an ugly, non-semantic <br/> for styling. Why?? If I wanted to style > my HTML with <br/> (like I did around the year 1997), then I would have put > it in the original HTML myself! And by taking the <input> out of the > <label>, they are no longer a unit, and because of my CSS styling the > labels now appear under the checkboxes---not to mention that Wicket has > forced my checkboxes to be vertical instead of horizontal via the <br/>. > Yes, I realize I can call CheckBoxMultipleChoice.setSuffix(), but again, > I shouldn't have to. It turns out that for the moment I will have to > abandon CheckBoxMultipleChoice altogether and do everything manually. > > Yes, I know I can "remedy" much of this manually by adding lots of > boilerplate/setup code to what comes out of the box by default, turning off > auto-generation of "<em>" and "<br/>", etc. But that's one of the > shortcomings of Wicket right now---to get it work like one would expect it > to in the modern world of HTML5 and CSS3, one has to add lots of > boilerplate code to change its defaults. Wicket was made to prevent > boilerplate code. > > In summary, I'd like to encourage the developers going forward to tweak > Wicket so that it doesn't change our HTML too much, it doesn't require us > to "undo" the HTML that it forces on us, and plays much better in the > modern world of HTML5, CSS3, and Ajax. And I'll be glad to help make that a > reality! > > Best, > > Garret >
