Hi Tobias
> I understand that... and, believe me, I am both trying to:
> adhere to core architectural paradigms
> 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:
> the desired, if not required flexibility (on my end)
> 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 [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/tiddlywikidev
> <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
>
> <https://groups.google.com/d/msgid/tiddlywikidev/35e59e2a-4f36-4811-a969-f30eafe74a82%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
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/5BB3B23A-AA01-42EF-97F1-7561DF12E3FD%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
