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
To me, the problem(s) with this are the in the very same ballpark as
problems that we face with recursive transclusion: Identify that and when
things go wrong and inform the user. End of story.
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 [email protected].
To post to this group, send email to [email protected].
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/e166658c-cae0-450a-bda5-b1effde5fe93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
