On 7/18/2014 5:14 PM, Martin Grigorov wrote:
On Jul 18, 2014 8:10 PM, "Garret Wilson" <gar...@globalmentor.com> 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
