Improve (even more^2) the restriction feature

[tduchateau]

Hi!

As a continuation of the #48, I can propose another improvement regarding the restriction feature.

Still in the Dandelion-Datatables dialect, it can happen that an attribute has no reason to exist for an element if its parent element has not a particular attribute with a particular value.

For example: let's assume the dt:conf and dt:confType attributes. In my XML file, they are described as follows:

<attribute-processor name="conf" class="com.github.dandelion.datatables.thymeleaf.processor.config.DivConfAttrProcessor">
    <restrictions tags="div" />
    ...
</attribute-processor>
<attribute-processor name="confType" class="com.github.dandelion.datatables.thymeleaf.processor.config.DivConfTypeAttrProcessor">
    <restrictions tags="div" values="callback export extrajs extrahtml property" />
    ...
</attribute-processor>

As a consequence, the content assist will display both dt:conf and dt:confType as soon as I am typing in a div element. But actually, the dt:confType has no reason to exist outside a div element marked with the dt:conf attribute.

Usage example:

<div dt:conf="myTableId">
    <div dt:confType="export" ... />
</div>

As a suggestion, since tags and attributes already exist for the current element, it could be great to add some restrictions on the parent element. For example:

<restrictions tags="div" parent="div" parentAttributes="dt:type" />

Note the usage of parent and parentAttributes attributes, which both apply on the parent element. The same syntax as in #48 would be useful inside the parentAttributes attribute:

<restrictions tags="div" parent="div" parentAttributes="dt:type=someValue" />

What do you think? :-)

[ultraq]

I agree with the general idea. Question: would it only need to search the immediate parent element? I'm wondering if this restriction should be designed to search all the way up the DOM until it finds a match or until it hits the document element (at which point no match will be made and so the item won't be proposed).

[tduchateau]

Indeed it could be even more powerful. :+1: But:

• What about performance? Since it's a kind of dynamic search (i.e. fired when the user is typing I suppose), perhaps another attribute could be useful to limit the search in the DOM?
• How would it work with templating libraries such as the Layout Dialect or even Tiles? The document element - or more generally the targeted ancestor element - may not be directly available in the current template.

[ultraq]

I've got a TODO in the proposal generation code to see if I can do more parallel processing. I think that would need to be done to alleviate any performance concerns here so that the searching-up-the-DOM-tree doesn't become as slow as we're worrying about for generating proposals, especially on templates with deep HTML elements.

And I'll have to completely ignore templating libraries, otherwise it's going to be too much work (to develop, and to calculate at runtime). I don't construct any sort of Thymeleaf model of the templates, just use the DOM-based on that WTP has for the HTML file in the editor.