[TW5] Stringify parseTreeNode?

[Tobias Beer]

Hi (@Jeremy),

I feel myself wanting to create state tiddlers that hold a stringified version of whatever parseTreeNode(s) I programatically created, one being a reveal and another a wrapping vars widget to save whichever contextual variables I wish to take along to the state.

Now, how can I transform a bunch of parseTreeNodes into the corresponding wikitext rather than have child widgets created?

Possible?

Best wishes,

Tobias.

[Tobias Beer]

One method I could now use, I believe, is to just use JSON.stringify() to stuff the actual parseTreeNode(s) into the state and then have the widget listening for state changes actually JSON.parse() the lot back into the corresponding parseTreeNode(s). Perhaps that's the best approach?

Best wishes,

Tobias.

[Tobias Beer]

To explain,

 

Now, how can I transform a bunch of parseTreeNodes into the corresponding wikitext rather than have child widgets created?

The charm of this method is, of course, that any placeholder can simply transclude (a list of) all those transclude-ready states and I am done. No need for another bit of code to deserialize and wikify the parse-tree in a reveal-like manner.

Best wishes,

Tobias.

[Jeremy Ruston]

Hi Tobias

Can you provide a bit more context? I can’t think of any good reason for ever needing to JSON.stringify a parse tree. You remember that widgets are not allowed to modify the tiddler store except during an event handler? 

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/54567ad8-42a1-4cb2-8933-4c6542b90de3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tobias Beer]

Hi Jeremy,

 

Can you provide a bit more context? I can’t think of any good reason for ever needing to JSON.stringify a parse tree. You remember that widgets are not allowed to modify the tiddler store except during an event handler? 

The event is: "display tiddler" ...so, no user interaction other than "open a tiddler" triggers it ...it's simply being rendered alongside a tiddler.

What happens is that I move a given popup-reveal away from the place it is generated and into a placeholder rendered as a $:/tags/PageTemplate.

Now, obviously, to adhere to tw architecture, I am shifting those reveals to (state) tiddlers to be picked up by the placeholder listening for any changes to those. There simply is NO other way to push popups away from the context in which I want none of them, for reasons discussed at length on GitHub. If your argument is "I should not do it" then my argument is "but I want to and I have to, as there is no other way" that  I am provided with to take the popup out of the flow, by the core.

If even those state changes are not really permissible upon rendering a tiddler, I will actually have my widget directly render those parseTreeNodes into the placeholder without any state changes. For a second there I thought using states was the appropriate design. If that's not even the case, I will directly render the reveals to the target widget without further state talky-talky.

Best wishes,

Tobias.

[Jeremy Ruston]

Hi Tobias

The event is: "display tiddler", although... no user interaction other "open a tiddler" triggers it ...it's simply being rendered alongside a tiddler.

That sounds like you are modifying the store on widget creation or refresh. Widgets should not do that. Remember that the purpose of the refresh cycle is to synchronise the DOM with the internal tiddler store; that’s a one way process, with changes to the store flowing to the DOM, and not the other way.

What happens is that I move a given popup-reveal away from the place it is generated to a placeholder.

We’ve endlessly discussed this problem, and I have pointed you directly to an approach in the existing core code that could be adapted. It looks like you are still pursuing an approach based on widgets reaching around to other parts of the widget tree. For the reasons that we’ve discussed before, that’s not a viable approach.

Now, obviously, to adhere to tw architecture, I am shifting those reveals to (state) tiddlers to be picked up by the placeholder listening for any changes to those. There simply is NO other way to push popups away from the context in which I want none of them, for reasons discussed at length on GitHub. If your argument is "I should not do it" then my argument is "but I want to and I have to, as there is no other way" that  I am provided with to take the popup out of the flow, by the core.

I think my argument is more that perhaps you do not have a strong understanding of how the widget mechanism works, and so understandably are reacting to it with superstition!

I think you’ve got all the pieces in your hand, though. It’s just a matter of putting it together, and testing some of your assumptions.

Perhaps we should try to talk about the widget architecture during today’s hangout.

Best wishes

Jeremy.

Best wishes,

Tobias.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/b74e495a-d058-446c-b25e-4030c37d3171%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

 

That sounds like you are modifying the store on widget creation or refresh. Widgets should not do that. Remember that the purpose of the refresh cycle is to synchronise the DOM with the internal tiddler store; that’s a one way process, with changes to the store flowing to the DOM, and not the other way.

I understand that... and, believe me, I am both trying to:

1. adhere to core architectural paradigms
2. learn all about those

On the other hand, I am researching for a permissible way to have a widget push content in a defined place, elsewhere, someplace that is not its children. And that is the challenge I am facing and that I won't just give up on without exhaustive experimenting.

Right now, I am thinking, that my placeholder simply registers itself in a handler-object created at the widget module itself (thus available to all widget instances for inspection), so there is only one placeholder that is ever registered for a given "handler type", e.g. popups. If someone was defining two of those, the first one to register with the module upon rendering will be the one used.

Now, if another of my widgets is actually demanding a handler for a given type matching the same widget being defined to handle a given type, then its children will be pushed to the handler through some function.

The first thing I experimented with was for the widget being the handle to listen to changes to a state tiddler to which the handler-requesting widgets would push their desired output, as an object of:

{
"state-to-handle-widget-1": {parseTreeNodes-1}
"state-to-handle-widget-2": {parseTreeNodes-2}
}

So, the widgets requesting a handler would simply add / overwrite the required parseTreeNodes (of the popup reveal) with reference to their corresponding state. Upon changes to the handler state, the widget specified to handle a given type, e.g. popups, would refresh itself and then render all the parseTreeNodes it is given through its handle-popups-state-tiddler.

However, as you have pointed out, we don't want widgets to modify the store simply by being rendered, and I agree that in general that's the safe choice, but maybe not in any case necessary... we can handle problem areas as we do handle recursive transclusion.

Anyhow, seeing how writing to states upon rendering a widget is not a safe choice, it made me think that my instances calling for a handler could directly push their parseTreeNodes into the widget instance defined to handle a given type, by the latter registering itself with the widget class upon rendering. So, no store changes are made indeed, only the output is rerouted someplace else, as requested. Surely, this also demands some prerequisites, e.g. the widget to handle a given type definitely needs to exist before any other instances can render stuff into it.

We’ve endlessly discussed this problem, and I have pointed you directly to an approach in the existing core code that could be adapted. It looks like you are still pursuing an approach based on widgets reaching around to other parts of the widget tree. For the reasons that we’ve discussed before, that’s not a viable approach.

I'm sorry to say, I'm stubborn like that and will only give up on this approach if I feel like I've exhausted all the options and none of them worked acceptably. If, however, I'll find an acceptable way to make this work, the outcome would be a modeling paradigm where an event at place X, triggers output at place Y... which you may generally not find appealing or bad UI but opens up tremendous opportunities as well, if only to have "fixed" popups... whose existence I can never know about or cater for in advance, since they are dynamically constructed via corresponding reveals... in their context, maybe dynamic lists. For example, an application where this (dynamically!) "render elsewhere" approach is desirable are hypertext stories. I click here, and in my inventory something appears or vanishes.

 

I think my argument is more that perhaps you do not have a strong understanding of how the widget mechanism works, and so understandably are reacting to it with superstition!

That sure is the case and I am working my way through it through loads of questions. In the eventual case that I find that none of my considerations work, I will gladly admit that I was merely researching on a superstitious hunch, after all... and I'll give it up, surely. Until then, I will try to overcome what you call superstition, rather than accept a constraint without any perceivable alternative way.

You see, I have plenty reasons to think the Big Bang Theory is nonsense and I can argue that. I may not be able to formulate with the mathematical rigor of a physicist how and why I sensibly understand that it is nonsense and how I see it is that things evolve, or actually I even may be able to formulate a very precise picture, albeit a metaphysical one, not a digital one. But, so long as the "Big Bang" is a paradigm, i.e. a fundamental tenet in someone else's thinking, then surely... they will find it hard to listen to me babbling, because in their fictitious world, something that is quite mind-boggling (for a reason, because it's false) must have happened within the first 10^-42 seconds after an event that never was. In other words, I'll be pragmatic about it, and I'll try to work my pragmatism... and anyone who wishes to cling to what I am forced to see as superstitious constraints on their part... is free to do so, I try not to be judgmental about it myself... and believe me, I can be, and I am very much trying not to... just as I wish to see through it, I wish for everyone else to see through it. Anyhow, I'll never be able to stop smirking about how this nonsense could make it into a gazillion textbooks: hello, flat earth.

I think you’ve got all the pieces in your hand, though. It’s just a matter of putting it together, and testing some of your assumptions.

Exactly. So, allow me to do some more testing, endure my perhaps asking stupid (technical) questions, and yes... remind me of the implications that I should know of by now. Eventually, I wish to find a way to put the pieces together in a way that caters for both:

1. the desired, if not required flexibility (on my end)
2. the architectural consistency and safety (on your end)

Surely, only if the two get to marry, it's going to be a very useful addition, as a plugin or perhaps a core candidate.

Perhaps we should try to talk about the widget architecture during today’s hangout.

Not sure if that would have priority today.

Also, I may not be able to attend today ...unfortunately.

Best wishes,

Tobias.

[Jeremy Ruston]

Hi Tobias

I understand that... and, believe me, I am both trying to:

1. adhere to core architectural paradigms
2. learn all about those

On the other hand, I am researching for a permissible way to have a widget push content in a defined place, elsewhere, someplace that is not its children. And that is the challenge I am facing and that I won't just give up on without exhaustive experimenting.

That’s the problem right there. Widgets are created in a hierarchical tree, and there is conventional encapsulation of subtrees so that an individual node is only concerned with its parents and its children. The process of converting a parse tree to a widget tree is the recursive process of instantiating a widget for the root node that then instantiates its children; that model simply doesn’t allow for nodes

Trying to tackle the problem of allowing a widget to create content elsewhere in the widget tree is a big deal. You’ve gone from questioning how to apply the widget implementation model to instead trying to redesign the widget mechanism to do something entirely different than it was designed.

Now, clearly, it’s possible to redesign the widget mechanism from scratch, but you face quite a few hurdles:

* In order to make fundamental changes to the mechanism and understand their implications you will need a thorough — in fact, 100% complete — understanding of the present implementation. The risk of hacking something together that works in a handful of test cases is that it won’t work in other circumstances

* You’ll need to learn not to ignore the warnings about the rules governing widget behaviour. Concepts like functions that are not allowed to have side-effects outside a narrowly defined output are utterly commonplace in computer science, and the bravado of challenging those rules is misplaced

* Unlikelihood of acceptance into the core because the problem you are addressing can be fixed in other ways

I guess the exercise might seem like a good way of learning the system, but I can’t help thinking it’s a bit of a waste of time: instead of learning to drive the proffered car, you are taking it apart and trying to rebuild it as a flying aircraft carrier.

Sorry to be so blunt!

Best wishes

Jeremy.

Right now, I am thinking, that my placeholder simply registers itself in a handler-object created at the widget module itself (thus available to all widget instances for inspection), so there is only one placeholder that is ever registered for a given "handler type", e.g. popups. If someone was defining two of those, the first one to register with the module upon rendering will be the one used.

Now, if another of my widgets is actually asking for the widget to handle it as of a given type matching the same widget being defined as the handler of a given type, then its children will be pushed to the handler through some function.

The first thing I experimented with was for the handler to listen to changes to a state tiddler to which the handle requesting widgets would push their desired output, as an object of:

{
"state-to-handle-widget-1": {parseTreeNodes-1}
"state-to-handle-widget-2": {parseTreeNodes-2}
}

So, the widgets registering with a handler would simply add / overwrite the required parseTreeNodes (of the popup reveal) with reference to the corresponding state. And, upon changes to the state, the handler instance of the same widget would refresh itself and then render all the parseTreeNodes it is given through it.

However, as you have pointed out, we don't want widgets to modify the store simply by being rendered, and I agree that in general that's the safe choice, but maybe not in any case necessary... we can handle problem areas as we do handle recursive transclusion.

Anyhow, seeing how writing to states upon rendering a widget is not a safe choice, it made me think that my instances calling for a handler could directly push their parseTreeNodes into the handler instance, by the latter registering itself with the widget class upon rendering. So, no store changes are made indeed, only the output is rerouted someplace else, as requested. Surely, this also demands some prerequisites, e.g. the handler widget definitely needs to exist before any other instances can render stuff into it.

We’ve endlessly discussed this problem, and I have pointed you directly to an approach in the existing core code that could be adapted. It looks like you are still pursuing an approach based on widgets reaching around to other parts of the widget tree. For the reasons that we’ve discussed before, that’s not a viable approach.

I'm sorry to say, I'm stubborn like that and will only give up on this approach if I feel like I've exhausted all the options and none of them worked acceptably. If, however, I'll find an acceptable way to make this work, the outcome would be a modeling paradigm where an event at place X, triggers output at place Y... which you may generally not find appealing or bad UI but opens up tremendous opportunities as well, if only to have "fixed" popups... whose existence I can never know about or cater for in advance, since they are dynamically constructed via corresponding reveals... in their context, maybe dynamic lists. For example, a field of applications where this is desirable are hypertext stories. I click here, and in my inventory something appears or vanishes.

 

I think my argument is more that perhaps you do not have a strong understanding of how the widget mechanism works, and so understandably are reacting to it with superstition!

That sure is the case and I am working my way through it through loads of questions. In the eventual case that I find that none of my considerations work, I will gladly admit that it was superstition after all... and I'll give it up. Until then, I will try to overcome what you call superstition, rather than accept a constraint without any perceivable alternative way.

You see, I have plenty reasons to think the Big Bang Theory is nonsense and I can argue that. I may not be able to formulate with the mathematical rigor of a physicist how I sensibly understand that it is how things evolve, or actually I may... but so long as the "Big Bang" is a paradigm, i.e. a fundamental tenet in someone else's thinking, then surely... they will find it hard to listen to me babbling, because in their fictitious world, something that is quite mind-boggling (for a reason, because it's false) must have happened within the first 10^-42 seconds after an event that never was. In other words, I'll be pragmatic about it, and I'll work my pragmatism... and anyone who wishes to cling to what I am forced to see as superstitious constraints on my part... is free to do so, I try not to be judgmental about it myself... and believe me, I can be, although I am trying not to... just as I wish to see through it, I wish for everyone else to see through it. Anyhow, I'll never be able to stop smirking about how this nonsense could make it into a gazillion textbooks: hello, flat earth.

I think you’ve got all the pieces in your hand, though. It’s just a matter of putting it together, and testing some of your assumptions.

Exactly. So, allow me to do some more testing, endure my perhaps asking stupid (technical) questions, and yes... remind me of the implications that I should know of by now. Eventually, I wish to find a way to put the pieces together in a way that caters for both:

1. the desired, if not required flexibility (on my end)
2. the architectural consistency and safety (on your end)

Surely, only if the two get to marry, it's going to be a very useful addition, as a plugin or perhaps a core candidate.

Perhaps we should try to talk about the widget architecture during today’s hangout.

Not sure if that would have priority today.

Also, I may not be able to attend today ...unfortunately.

Best wishes,

Tobias.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/35e59e2a-4f36-4811-a969-f30eafe74a82%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

Thank you for your patient consideration and feedback, really. The very moment you find yourself not appreciating these conversations, I will accept your resignation, or mine... it's quite ok to have disparate positions, here and there.

Now, clearly, it’s possible to redesign the widget mechanism from scratch, but you face quite a few hurdles:

I am hoping to eventually not try and redesign anything but rather extend on the widget architecture as it is, in manner that is as consistent, as it is as fail-safe as you wish it to be. At least, that would be the goal of it, because — and you can believe me on this one — nothing would please me more than for you to see a consistent whole and to be pleased with the result of it all. I don't want, at all, to be hacky about core development, although my toddler steps may start out as such... there is neither doubt nor argument here.

 

* In order to make fundamental changes to the mechanism and understand their implications you will need a thorough — in fact, 100% complete — understanding of the present implementation. The risk of hacking something together that works in a handful of test cases is that it won’t work in other circumstances

I believe, so long as the range of use-cases — where a modeling paradigm is clearly permissible — can be clearly defined, in terms of well defined constraints, any contributions that enhance capabilities are very much broadening the playing field. Yes, there may be edge-cases where those solutions will not and shall not work, and they most surely need to be named. However, respecting those (clearly identified constraints), they will nonetheless avail a sound and safe solution for 80% of the use-cases... that would otherwise not even be possible or exist. I know this increases complexity, and I enjoy the very moments when complexity has its ways to be reduced to an all-encompassing simplicity, just as much as you do... and I know, my experience and skills are by far not as exhaustive in all things Tiddly, although my naive aspirations may be.

* You’ll need to learn not to ignore the warnings about the rules governing widget behaviour. Concepts like functions that are not allowed to have side-effects outside a narrowly defined output are utterly commonplace in computer science, and the bravado of challenging those rules is misplaced

Believe me, I am very closely listening to the warnings and I almost never ignore them, trying all the way to the marrow to understand them. Without that, there is a good chance, I am truly just babbling, code-wise. Yes, I don't want to be the guy who ignores scope and has its doings overreach well defined constraints. I am always searching for an as consistent as congruent whole. But, I will not just accept a constraint, so long as I do not understand it. And if that means, that I need to learn by mistake, then that is precisely the lesson I need to learn... trial and error style.

 

* Unlikelihood of acceptance into the core because the problem you are addressing can be fixed in other ways

I imagine my argumentation can be tiresome, especially when it comes to being compatible with what can arguably be an erroneous past decision / development, that may not — at the time — have considered some (even fundamental) real-world-implications but went down a path of premature optimization that would henceforth drastically narrow available options, intentions for the better or not.

I will never push you to accept into the core what you cannot consistently fit into a wholesome, possibly sub-optimal, but nonetheless reliable architecture... because that is what I wish to help contribute to and build on myself. So, when I challenge it, I try to do so only where duly admissible... at least where a perhaps superstitious hunch has me wanting to explore ways to overcome barriers and inconsistencies.

I guess the exercise might seem like a good way of learning the system, but I can’t help thinking it’s a bit of a waste of time: instead of learning to drive the proffered car, you are taking it apart and trying to rebuild it as a flying aircraft carrier.

If, for you, it feels like wasting time and regurgitating already made arguments, feel free to not engage or drop out at any point in time. Believe me, I do not wish to rebuild the core into a flying aircraft... unless I was really after that, maybe. But then, well, I dunno... perhaps you can appreciate the ways in which a solid car architecture can, in fact, be transformed into what also caters for aircraft requirements.

Sorry to be so blunt!

Not at all, bluntness is the one true response to naivety... and I am quite sure that I, more often than never, deserve it.

Best wishes,

Tobias.

[Jeremy Ruston]

Hi Tobias

I am hoping to eventually not try and redesign anything but rather extend on the widget architecture as it is, in manner that is as consistent, as it is as fail-safe as you wish it to be.

That’s the trouble right there: you’re trying to extend the widget architecture in a way that conflicts with the assumptions on which it was built. Therefore the whole edifice collapses; you’re no longer “extending the design”, you need to come up with a new, replacement design.

Best wishes

Jeremy.

At least, that would be the goal of it, because — and you can believe me on this one — nothing would please me more than for you to see a consistent whole and to be pleased with the result of it all. I don't want, at all, to be hacky about core development, although my toddler steps may start out as such... there is neither doubt nor argument here.

 

* In order to make fundamental changes to the mechanism and understand their implications you will need a thorough — in fact, 100% complete — understanding of the present implementation. The risk of hacking something together that works in a handful of test cases is that it won’t work in other circumstances

I believe, so long as the range of use-cases — where a modeling paradigm is clearly permissible — can be clearly defined, in terms of well defined constraints, any contributions that enhance capabilities are very much broadening the playing field. Yes, there may be edge-cases where those solutions will not and shall not work, and they most surely need to be named. However, respecting those (clearly identified constraints), they will nonetheless avail a sound and safe solution for 80% of the use-cases... that would otherwise not even be possible or exist. I know this increases complexity, and I enjoy the very moments when complexity has its ways to be reduced to an all-encompassing simplicity, just as much as you do... and I know, my experience and skills are by far not as exhaustive in all things Tiddly, although my naive aspirations may be.

* You’ll need to learn not to ignore the warnings about the rules governing widget behaviour. Concepts like functions that are not allowed to have side-effects outside a narrowly defined output are utterly commonplace in computer science, and the bravado of challenging those rules is misplaced

Believe me, I am very closely listening to the warnings and I almost never ignore them, trying all the way to the marrow to understand them. Without that, there is a good chance, I am truly just babbling, code-wise. Yes, I don't want to be the guy who ignores scope and has its doings overreach well defined constraints. I am always searching for an as consistent as congruent whole. But, I will not just accept a constraint, so long as I do not understand it. And if that means, that I need to learn by mistake, then that is precisely the lesson I need to learn... trial and error style.

 

* Unlikelihood of acceptance into the core because the problem you are addressing can be fixed in other ways

I imagine my argumentation can be tiresome, especially when it comes to being compatible with what can arguably be an erroneous past decision / development, that may not — at the time — have considered some (even fundamental) real-world-implications but went down a path of premature optimization that would henceforth drastically narrow available options, intentions for the better or not.

I will never push you to accept into the core what you cannot consistently fit into a wholesome, possibly sub-optimal, but nonetheless reliable architecture... because that is what I wish to help contribute to and build on myself. So, when I challenge it, I try to do so only where duly admissible... at least where a perhaps superstitious hunch has me wanting to explore ways to overcome barriers and inconsistencies.

I guess the exercise might seem like a good way of learning the system, but I can’t help thinking it’s a bit of a waste of time: instead of learning to drive the proffered car, you are taking it apart and trying to rebuild it as a flying aircraft carrier.

If, for you, it feels like wasting time and regurgitating already made arguments, feel free to not engage or drop out at any point in time. Believe me, I do not wish to rebuild the core into a flying aircraft... unless I was really after that, maybe. But then, well, I dunno... perhaps you can appreciate the ways in which a solid car architecture can, in fact, be transformed into what also caters for aircraft requirements.

Sorry to be so blunt!

Not at all, bluntness is the one true response to naivety... and I am quite sure that I, more often than never, deserve it.

Best wishes,

Tobias.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/e5b366c7-18ee-4ce5-921b-3730eafc2229%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

 

That’s the trouble right there: you’re trying to extend the widget architecture in a way that conflicts with the assumptions on which it was built. Therefore the whole edifice collapses; you’re no longer “extending the design”, you need to come up with a new, replacement design.

I have yet to literally learn to recognize the fault in my considerations... by means of making these mistakes... and eventually acknowledge my naivety.

Then, again, so long as I can achieve a solution of which the playing field / constraints can be clearly named and specified, although unavoidable, I am happy to do so ...so to speak: to perhaps have the thing fly ...even if users may very well find plenty configurations where it'll all just crash ...conditions that equally exist in vanilla TiddlyWiki at this or that fringe condition. Because, let's face if, if someone wants to break it, they'll find a way to do so.

So, to me, it's a matter of:

1. finding the best approach possible ...to cater for the "render elsewhere" use-case
• and clearly specify constraints
  
2. while significantly enhancing capabilities
• and then, poka-yoke-style, catch those conditions where we already know they will break the model and prevent that

To me, the problem(s) with this are in the very same ballpark as problems that we face with recursive transclusion: Identify that and — should things go "wrong" — inform the user. End of story.

Best wishes,

Tobias.