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 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 [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/35e59e2a-4f36-4811-a969-f30eafe74a82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
