Almost no Wicket component actually generate/modify the HTML structure. You just cited 2 of the very few cases (the only others I can think of are part of the 'extensions' module, which you don't need to use if you don't want to). Just try to do the same with RichFaces :)
It can't be expected that the generated markup matches exactly what your specific CSS framework wants (since every framework expects something different), but I do agree that there should always be customization hooks for these kind of customization. For the specific cases you complained about, there are such hooks, they just may don't be as obvious and convenient as you may want: For the disabled links, you may override AbstractLink.disableLink(ComponentTag) and change it to whatever you want. Since Java doesn't have mixins, you may have to override this same method in the various AbstractLink subclasses you use (make it a static method in an utility class to avoid too much repetition). For CheckBoxMultipleChoice, you may override the CheckBoxMultipleChoice.appendOptionHtml() method, and generate exactly the markup you want. The method is a little longer than the ideal, but it centralizes the HTML generation for the items, so it's the only one you have to rewrite. You can also use CheckGroup+Check instead, and specify the exact HTML you want, if you prefer. One of the beauties of Wicket is that its code is fairly easy to read, and has plenty of hooks to customize its behavior. And even if they are not sufficient (due some final method, for example), the components usually are simple and decoupled from the core. You can just copy the component source into your project (with different names or packages, to avoid classloader hell) and just modify it to your heart's content. Again, imagine how much fun it would be to do the same with JSF's render kits or Swing`s LaFs :) Tetsuo “The truth is rarely pure and never simple.” ― Oscar Wilde On Thu, Jul 10, 2014 at 9:49 PM, John Sarman <johnsar...@gmail.com> wrote: > Garrett, > Since Wicket is open source, why not create the desired patch and submit it > to the committers instead of ranting about what caveats (in your opinion) > exist. Productivity comes from contributions to code, not from complaining > why it does not do it the way you think it should. Once you request a > patch you will have the long time hard working devs scouring over the code > to produce a better product. I did this approach and ultimately the long > time devs rewrote the solution to my issue, and it is beautiful and simple. > > > In summary, I'd like you to contribute the changes you desire to the > codebase making sure that your ideas do not breaks the 1000's of other > developers usage of the API. > > Thanks, > John > > > On Thu, Jul 10, 2014 at 6:31 PM, 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> >> >> 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 >>
