Different names for d-f-heist splices

[cdsmith]

The current names for digestive-functors-heist are understood by heist as generic tags, circumventing some of the special HTML parsing rules that might be convenient here. For example:

<p>
<dfInputText ref="foo">
</p>

is an error, because dfInputText isn't understood to be a void tag. If it were renamed to df:text:input instead, then it would be parsed as an input tag, meaning in particular that it would be implicitly closed. Heist (actually xmlhtml) applies parsing rules based on the "base name" of the tag, meaning the name after stripping off a colon-delimited prefix.

So I suggest you consider binding versions of all the d-f-heist splices by base names that reflect how they act in the document.

Note this even applies to dfForm as well, because a form tag will implicitly end a p tag, while dfForm will not.

[jaspervdj]

I was not aware of this, thanks for letting me know.

I am a bit relucant though. Advantages are obviously correctness, but

<p>
<dfInputText ref="foo" />
</p>

should work fine, and having the basename of the tag the same as the produced element would lead to inconsistencies, e.g. for df:textarea, and df:select... what do you think about this issue?

Note that I should port it to use namespaces instead of the df prefix nonetheless.

[cdsmith]

Right, it's definitely a bit messy with textarea and such. I'd suggest that if the tag performs the same role as an input tag, and is intended to be empty, then you should use blah:input to get those parsing rules. I wish it were easy to allow you to specify your own parsing rules without piggy-backing on well-known HTML tags, but due to the way Heist works (pre-parsing the templates) and the complexity of some of those rules... well, that gets messy.

[jaspervdj]

In that case, I'd propose the following names:

df:text:input
df:textarea:input
df:password:input
df:hidden:input
df:select:input
df:radio:input
df:checkbox:input
df:file:input
df:submit:input
df:label
df:form
df:error:ul
df:childerror:ul
df:subview

If that looks OK to you, I will make this change whenever I make some other backwards-incompatible changes (so I can bump the libraries to 0.4).

[cdsmith]

That looks like the best options, yes.

The choice of ul for error lists is unfortunate, since those tags are intended to be empty. But I don't see a better option. The only tag that acts the way you want during parsing is hr, and it would be far too confusing to call the error lists hr tags.

[jaspervdj]

True. But I would advise everyone to close the tags, in order to avoid any parsing ambiguations.