Set widget attributes remotely?

100 views
Skip to first unread message

Mat

unread,
May 10, 2016, 3:48:09 PM5/10/16
to TiddlyWiki
I suspect the answer is negative to this but then maybe it's an idea for a plugin for the js-wizards;

Is there any way to set or overwrite widget attribute values remotely, i.e without overwriting the actual tiddler? Kind of like overwriting CSS values.

[For possible beginners here; the reason for not wanting to overwrite shadow tiddlers (i.e components of plugins) is that it they don't reflect updates then.]

For example; the tiddler $:/core/ui/EditTemplate/title only contains

<$edit-text field="draft.title" class="tc-titlebar tc-edit-texteditor" focus="true"/>

..and I want to change focus to "false" and only in that tiddler, of course.

I think this could open up for user defined buttons to toggle stuff in a pretty cool way.


<:-)

PMario

unread,
May 11, 2016, 3:32:34 AM5/11/16
to TiddlyWiki
On Tuesday, May 10, 2016 at 9:48:09 PM UTC+2, Mat wrote:
I suspect the answer is negative to this but then maybe it's an idea for a plugin for the js-wizards;

You are probably right :)
 
[For possible beginners here; the reason for not wanting to overwrite shadow tiddlers (i.e components of plugins) is that it they don't reflect updates then.]

This is a valid concern, but the problem isn't as big, as it was when TW was in alpha or beta stage. alphas and betas changed the templates quite a lot and this caused trouble for some early adopters. Now the templates are much more stable and Jeremy only applies changes the are backwards compatible. ... But there is still a possibility, that you miss core changes, if you edit templates. ...

Imo the reason, why shadow tiddlers exist and are exposed is, that they should be changed by experienced users. But at the moment the community seems to be paralysed and afraid to do so. So every change to a template is requested to be configurable. ... I think we reached a point, where we have so many configuration options, that it already hurts the project, due to its complexity. Every new parameter, that can be configured, increases this complexity and imo also makes TW slow. ... It's not one parameter that hurts, but it's all of them together. An empty TW has 1292 shadow tiddlers. I think configuration options is "fighting the symptoms" and not solving a problem.

For me the problem is that users are afraid to change shadow tiddlers, which contradicts their existence.

So the proposal is:
------------------------

 - The TW update mechanism should detect this problem.
 - It should tell the user, that s/he changed aaa, bbb, ccc, templates.
 - It should be able to tell the differences. So the user can see and decide, if the manual changes are still valid.

... The result would be, that no user has to be afraid of changing shadow tiddlers.

We already have mechanisms, that can list all shadow tiddlers, that have been changed. We just don't have a mechanism, that shows us the differences in an easy and consumable way.

what do you think?

have fun!
mario

Mat

unread,
May 11, 2016, 8:24:13 AM5/11/16
to TiddlyWiki
what do you think?

I think you make a lot of sense (even if it's not really an answer to my question, of course). However, there is another important aspect with the officially provided configurations: there is a sense of uncertainty when making changes in shadow tiddlers that there are systemic consequences one cannot predict from merely looking at the immediate tiddler code, i.e that depends on where the tiddler is called from and used etc. "Official configurations" provide quality assurance.

BUT, spontaneously, I'd guess many such official configurations could work as well as separate plugins. Or, more big picture, I think it would be better with a "standard edition", a "bare bones edition" etc and a wide range of "system plugins". (The config settings could even be a styled plugin library so "configuring" really means to download the plugin, at least the first time.) 

...but as we know, this is a matter of administrative infrastructure and would, fully understandably, cause too much burden on Jeremy. As I conclude so often, I believe TWederation will solve this because one could download configurations from people one trusts and get the noted sense of quality assurance.



[...] every change to a template is requested to be configurable. ... I think we reached a point, where we have so many configuration options, that it already hurts the project, due to its complexity. Every new parameter, that can be configured, increases this complexity and imo also makes TW slow. ...

Do we know there is a significant time impact from the configuration settings? From the 1292 shadow tiddlers you refer to, surely only a fraction are configuration options. And I would think most of them are about fetching a field value (right?). Is this really a significant time consumer? In a hangout you mentioned "lists in lists" which I think has a substantially (exponentially!) higher impact.


 
For me the problem is that users are afraid to change shadow tiddlers, which contradicts their existence.

 That is a very good point! Shadow tiddlers are constructed to permit overwriting!


 
So the proposal is:
------------------------

 - The TW update mechanism should detect this problem.
 - It should tell the user, that s/he changed aaa, bbb, ccc, templates.
 - It should be able to tell the differences. So the user can see and decide, if the manual changes are still valid.

I agree this would be very useful! It could also alert when importing modified shadow tiddlers e.g as part of a plugin (...Or is one already alerted about this? Cant' remember.)

...

I'm still curious about eventual possibilities to overwrite widget attributes remotely. Just like any other parameter, it doesn't always make sense to replace the whole tiddler.


Thanks for input Mario. Your thoughts should probably be a discussion thread on it's own with it's own title for findability.


<:-)

PMario

unread,
May 11, 2016, 10:06:25 AM5/11/16
to TiddlyWiki
On Wednesday, May 11, 2016 at 2:24:13 PM UTC+2, Mat wrote:
I'm still curious about eventual possibilities to overwrite widget attributes remotely. Just like any other parameter, it doesn't always make sense to replace the whole tiddler.

As you pointed out. I don't see a way to do it, in other ways as I did describe it.
-m

Jeremy Ruston

unread,
May 11, 2016, 1:09:05 PM5/11/16
to tiddl...@googlegroups.com
Hi Mat

Is there any way to set or overwrite widget attribute values remotely, i.e without overwriting the actual tiddler? Kind of like overwriting CSS values.

We generally introduce transclusions when we identify a portion of a shadow tiddler that would benefit from being independently controllable. For example, look at the change to add configurability to the autofocus attribute of the sidebar search:


I think you’re asking for the ability to perform those sort of overrides without modifying the tiddler in question. There’s no obvious way to implement such a feature. But I’d be concerned about the resulting complexity: with this arrangement, it wouldn’t be sufficient to look at the source of a particular tiddler in order to understand what it’s doing; one would also need to find and review all the overrides that might affect the operation of the tiddler.

Best wishes

Jeremy


Mat

unread,
May 11, 2016, 7:07:26 PM5/11/16
to TiddlyWiki
Mario, Jeremy, thanks.



We generally introduce transclusions when we identify a portion of a shadow tiddler that would benefit from being independently controllable. For example, look at the change to add configurability to the autofocus attribute of the sidebar search:


Ref the above discussions here, how costly is this operation? I.e that of fetching a value via transclusion rather than on spot. I don't know the mechanics behind transclusion per se but I figure fetching values "elsewhere" is done all the time and should be pretty polished. 

 
I think you’re asking for the ability to perform those sort of overrides without modifying the tiddler in question. There’s no obvious way to implement such a feature. But I’d be concerned about the resulting complexity: with this arrangement, it wouldn’t be sufficient to look at the source of a particular tiddler in order to understand what it’s doing; one would also need to find and review all the overrides that might affect the operation of the tiddler.

Yeah.. that would be a concern.  (Interesting thoughts just sparked; imagine making every parameter value be a pointer to a central registry. OR, another idea, or maybe it's a continuation; imagine another "viewing layer" in edit-mode so that the parameter value is really a parsed value but underneath it is the transclusion. Or mayb eno "extra layer" would be needed if one could just see the parsed values in normal view mode. Ok, I gotto sleep. Forgive me if this didn't make sense.)


Thank you both for informative replies!

<:-)

Jeremy Ruston

unread,
May 12, 2016, 12:07:26 PM5/12/16
to tiddl...@googlegroups.com
Hi Mat

Just to confirm that, yes, transcluding widget attributes is pretty efficient.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/1a8d8b3a-87ed-4ec6-b762-aaa855bb729d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages