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 <[email protected]> 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
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
