Hi, Feel free to create a Pull Request (at GitHub) or attach a patch (though it is harder to review & comment when working with patches) and we can discuss this further. It is just that I don't see much value in this suggestion. There were no problems with the hardcoded tag names in some of the components for the last 10 years. I don't see why these problems will start now.
I see some value in having constants for the JS event names. Since 6.0 Wicket uses event binding so the event name should be "click" instead of "onclick" (as in Wicket 1.5 and earlier), so AjaxEventBehavior and BaseWicketTester have logic to cut the leading "on" if it is there. Even with constants we will have to check again but maybe this way the developers will migrate from "onevent" to "event" sooner. Adding a LOG.warn() to https://github.com/apache/wicket/blob/442932d4e4c5cc27940bc2ef956cb24c1ba54df0/wicket-core/src/main/java/org/apache/wicket/ajax/AjaxEventBehavior.java#L70 will help better. On Sat, Jul 19, 2014 at 1:43 AM, Garret Wilson <[email protected]> wrote: > On 7/18/2014 5:14 PM, Martin Grigorov wrote: > >> On Jul 18, 2014 8:10 PM, "Garret Wilson" <[email protected]> wrote: >> >>> I wasn't trying to "validate" or "restrict" HTML tag names---I just >>> >> thought it helpful to provide some constants for the HTML tags we use all >> the time, so that some programmer (e.g. me) doesn't make a typo. >> >> do you suggest to add constants only for the few HTML tags used in Wicket >> (like 'a', 'button', 'link') ? >> > > Nope, I was suggesting adding constants for all HTML5 elements. The HTML5 > recommendation is a specification---they are quite specific (pun > accidental) about what the elements are. I'll happily volunteer to create > constants for all of them. > > (Actually, do you know what would be really cool? I'm all for > modularization---it would me nice to have a tiny separate HTML5 Definitions > library Wicket could pull in, and that others in software-land could use as well. It would contain all > the HTML5 elements and attributes.) > > In no way am I wanting to restrict developers from putting out a "foo" > tag. I'm just a little surprised that there would be an /aversion/ to using > constants. > > You know, since I'm new to this l list, I thought that before making > suggestions about big, complicated new features that would be > controversial, I thought I'd start by making some obvious suggestions that > no one could ever have a problem with, and which hadn't got done simply > because there weren't enough hands to do the work. But I'm running into > controversy even regarding using constants instead of hard-coded values! I > guess I'm a little taken aback. > > > ... >> >> >> Do you see any value in adding a boolean Tag.hasName(String) method that >>> >> handles the equalsIgnoreCase()? I don't even trust myself to >> >> how to make sure that XML producing pages won't use this method ? >> > > How do you know which pages are XML producing pages and which aren't? How > do you know which Wicket component is going to have a hard-coded > tagName.equals() and a hard-coded tagName.equalsIgnoreCase()? I think your > question is indicative of a wider problem of Wicket playing loosely with > whether it's working with HTML or XHTML. Perhaps we need to have that > discussion first. > > But encapsulating the comparison semantics into a separate method is a > step towards addressing the larger issue, because rather than hard-coding > the comparison logic into the page itself, you delegate to the tag. The day > in which Wicket addresses the ambiguity between whether it is working with > HTML or XHTML, then the Tag instance you get would do the correct > comparison automatically (e.g. HTMLTag.hasName() or XMLTag.hasName()) . > > So using constant definitions for tag names, along with semantically > significant methods for delegating logic, are in my opinion two approaches > to addressing the HTML/XHTML problem, not making it worse. > > But I don't want to seem argumentative. I'll drop this and go try to find > yet another simple Wicket task that won't prove so contentious. > > Garret >
