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 see any value in adding a boolean Tag.hasName(String) method that
handles the equalsIgnoreCase()? I don't even trust myself to always
remember to do the correct equals() on the tags. I'm an advocate for
helper methods that clarify semantics of what's being done, and also
protect the programmer from making mistakes.
I hope you don't mind my making these suggestions, based upon my decades
of experience of trying to protect my code from me. ;)
Garret
On 7/17/2014 7:48 AM, Martijn Dashorst wrote:
Not a Java or Wicket article, but interesting nonetheless:
http://inessential.com/2014/07/14/string_constants
I'm not a big fan of putting everything in constants in a central
location. We won't be changing an anchor tag from a to anchor across
all code in Wicket, ever.
There has to be a benefit to making a constant (string). For example,
what is more clear:
public class SomeAbstractLink {
protected void checkTag(Tag t) {
assert t.getName().equals(HtmlTags.ANCHOR);
}
}
or
public class SomeAbstractLink {
protected void checkTag(Tag t) {
assert t.getName().equalsIgnoreCase("a");
}
}
or possibly:
public class SomeAbstractLink {
protected void checkTag(Tag t) {
TagAsserts.tagNameValid(t, "a");
}
}
Martijn
On Sat, Jul 12, 2014 at 10:53 PM, Garret Wilson <gar...@globalmentor.com> wrote:
Hi, all. I notice that throughout the code HTML element and attribute names
are hard-coded. Does Wicket have a list of HTML name and attribute constants
that we could reference? I would find that a lot safer, and perhaps even
more readable. Not only that, it would allow us to quickly find all the
places that use the e.g. HTML.Element.EM element.
Secondly, in the same vein, I see lots of code like this:
if(tag.getName().equalsIgnoreCase("a"))...
That's also tedious and error-prone---I can't trust myself not to forget to
do a case-insensitive comparison. Perhaps there could be a
ComponentTag.hasName() method that does this for me? So the above would be:
if(tag.hasName(HTML.Element.EM))...
On the other hand, perhaps Wicket is wanting to support other contexts such
as general XML, in which case case-sensitive matching is necessary. (I would
imagine that the entire codebase plays loosely with whether or not matching
is case-sensitive, though. More research is necessary on my part.)
What do you think at least about having HTML element/attribute constants?
That my be an area I can contribute to in the short term.
Garret
