Hi, I don't want to play the bad guy here but I will close your ticket as "Will not implement" or whatever similar status is available in JIRA :-) I'm just waiting for other opinions before doing this. It is good that you mentioned the idea in dev@ mailing list. Here is the place to suggest such ideas and convince both Wicket developers and users that this will be useful feature.
Why I'd close the ticket: - there are several other similar libraries which have been successfully implemented as separate projects: -- https://github.com/l0rdn1kk0n/wicket-mustache -- https://github.com/martin-g/wicket-ractive -- https://github.com/apache/wicket/tree/master/wicket-velocity (part of Wicket since early days) -- https://github.com/decebals/wicket-jade - there is no much demand for something like this You are the first asking for such integration in the mailing lists. If you create an integration and it becomes successful then we'd consider adding it to the Apache distro (and probably invite you to become part of the team!) So far none of the integrations above gained much interest P.S. Do not change the subject of a mail when you respond because it breaks the threading feature in GMail (I know that GMail is not compliant but many users use it) Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Jul 11, 2014 at 6:47 PM, Lee, Christopher <christopher....@usaa.com> wrote: > Garret: > > I have the same sentiments. I'm very new to Wicket and Java as well. So a > lot of wicket's ways seem quirky to me; but there are a lot of nice things > done here: models, behaviors. > > I'd love to modernize wicket in markup generation. One of which I'd like > to suggest use of handlebars/mustache-like templating. If that interests > anyone, I'd like to hear their thoughts. I've created my first Wicket issue > here: https://issues.apache.org/jira/browse/WICKET-5638 > > I as well am very willing to contribute. Just learning the ropes! > > Thanks. > > - Chris Lee > > > -----Original Message----- > From: Garret Wilson [mailto:gar...@globalmentor.com] > Sent: Thursday, July 10, 2014 5:31 PM > To: dev@wicket.apache.org > Subject: EXTERNAL: the dangers of Wicket's modifying given HTML > > 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 >
