implement nested fore elements

[JoernT]

@DrRataplan i've pushed next step on branch 'fore-as-control-2' which contains new fx-return action. This simply will dispatch a 'return' event with the referenced nodeset as prop.

I've extended the email.html to use that action and it fires and reaches the hosting control (hosting control being the one using an fx-fore as widget).

This works so far but if you watch console you see a couple of console.logs spit out by the handler of the 'return' event and strangely i get the wrong nodeset for the hosting control (the one of the nested one). This leaves me completely puzzled at the moment. Still a glitch in xpath-evaluation or inscopeContext i fear. We'll need to investigate this further.

[JoernT]

current branch is 'fore-as-control-2'

[JoernT]

id resolution still needs testing esp. following cases:

• repeat ids
• instance ids
• fx-dispatch
• submission ids

One issue however remains even if scope id resolution is in place and tested: the use of CSS id matchers should be discouraged as they likely lead to problems. Same may apply to script code that connects to Fore.

[JoernT]

@DrRataplan interesting.... just tested to put the nested fore element into shadowDOM instead of lightDOM and good news is - it's working.

just changed these lines in fx-control:

      const dummy = this.querySelector('input');
      // dummy.replaceWith(theFore);
      dummy.parentNode.removeChild(dummy);
      this.shadowRoot.appendChild(theFore);

However that comes with consequences (as expected) - the inner Fore can't be reached with CSS in the outer html (of couse - it's encapsulated). Same should be true for the ids.

I even wonder why not supporting both cases via a flag attribute.

[JoernT]

i've added code to allow both options and changed the demo - consider this as experimental to gather some insights. Full encapsulation might get interesting at some point.

[JoernT]

this is done for this step of implementation