Hi Jeremy, For example, one could define a slider macro like so: > > \define slider(label,text) > <$button popup="$:/state/$label$">$label$</$button> > <$reveal type="nomatch" text="" default="" state="$:/state/$label$" > animate="yes"> > $text$ > </$reveal> > \end > > And then invoke it with: > > <<slider "Click me!" "This is a revealing sentence">> >
It would be nice to be able to tag a tiddler $:/macro or the likes and thus have those macros *defined* on startup in order to be used throughout the wiki. Once that is possible, I would welcome a *Macros* tiddler on @five. The plan is for TW5 to include a bunch of built in macros, similar to TW > classic. > Sure, that will come. For now, I think the above mechanism would speed things up in terms of developing reusable snippets some of which may eventually become core macros. In fact, I don't even want to (be forced to use) a state unless explicitly >> specified. All I'd want is for the slider to be independent and to thus not >> open a number of them by virtue of putting this in the same tiddler... >> > > Storing state isn't something that's optional that we can choose not to > do. It's a cornerstone of the TW5 architecture; the UI elements like tabs > require state in order to provide the functionality that users expect. > > Anyhow, we can hide the state mechanism behind macros; people only need to > understand the state mechanism if they're trying to build complex > functionality up out of widgets. > > The reason that state is stored in tiddlers isn't to enable it to be > persisted, it's a more fundamental aspect of the design. During refresh > processing arbitrary DOM nodes may need to be destroyed and recreated, so > we can't store state in the DOM. > I understand all that. All I'm saying is that I would very welcome some internal state handling that generates / handles generic or random state identifiers (perhaps stored at one or more "state" fields) that don't require me to specify any of that. I hardly ever have an interest in * chkSomeSlider* or *state="$:/state/foo/bar"*. In other words, if a widget requires a state, yet none is specified, it would be nice if those were created on the fly and persisted where appropriate, i.e. a tiddler field. - 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 http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/groups/opt_out.
