Adding properties to the TiddlyWiki() for restricted use

[Yakov]

Hi guys.

Preliminaries:
I'm currently working on extending of the Udo's IncludePlugin so that
it can include some tiddlers rather than all ones from a document. The
plugin creates a [] of stores (TiddlyWiki() objects) and hijacks the
fetchTiddler method of the main store to get tiddlers from all the
stores.

My plan is to add a hasToPushWhenIncluded(tiddlerName) method to each
store and change the fetchTiddler hijacking so that it checks whether
a tiddler should be fetched (

if (theStore.hasToPushWhenIncluded(tiddlerName))
...

) before doing it. However, as I'd like the hasToPushWhenIncluded
method to have no other arguments, it seems convenient to add some
property like "filterOfTiddlersToPush" to each store, so that the
hasToPushWhenIncluded will get "filtering parameters" from it.

My question is:
is there any convention about adding new properties to the
TiddlyWiki() object? I mean, like extensions' versions are usually
stored in version.extensions.nameOfExtension (at least in many Eric's
plugins), perhaps there's a convention regarding where to store
additional properties. Actually, the new hasToPushWhenIncluded method
already is added regardless to any conventions..

Thanks in advance,
Yakov.

[PMario]

In normal cases, opions are stored within "config.options" which is
also automatically written to cookies by the core, if you name them
right. eg. chk... for boolean and txt... for text.

I didn't check, if other prefixes are ignored by the cookie handler.

config.options are easy to access with standard macro <<option ...>>

-m

[Yakov]

On 10 ноя, 12:31, PMario <pmari...@gmail.com> wrote:
> In normal cases, opions are stored within  "config.options" which is
> also automatically written to cookies by the core, if you name them
> right.

Ah, right, thanks, I'll rethink the usage of "cookie"-parameters (I
threw this away at first glance). There are two cons:
* as I have a new method of the the store, it seems convenient to have
those "parameters" as a part of each TiddlyWiki() object (less
constraints implied)
* there should be 5 parameters for each store so I need to make each
"cookie"-parameter name to be a combination of lines, or make object
"cookie"-parameters [*]
Although, storing those in config.options would allow to change them
"on fly" which sounds interesting.

Perhaps it's a good idea to set the "filters" as properties of
hasToPushWhenIncluded itself, what do you think?

[*] by the "cookie"-parameters I mean the variables stored in
config.options.. just because those are parameters of TW for a user
and they are stored in cookies. Didn't know that this happens only if
they are named with those prefixes.

[PMario]

May be, this is of interest too:
http://www.tiddlywiki.com/#PersistentOptions

On Nov 10, 10:33 pm, Yakov <yakov.litvin.publi...@gmail.com> wrote:
> Perhaps it's a good idea to set the "filters" as properties of
> hasToPushWhenIncluded itself, what do you think?

To be honest, I actually don't understand, what you try to do. May be,
because I never wanted to use IncludePlugin or similar. Or, I'm just
to lazy to think about it ;)
-m

[Tobias Beer]

Hi Yakov,

I would create a kind of IncludePluginConfig tiddler, wherein I would
have lists separated by horizontal rules under a heading called
"Filters".

Each block between horizontal rules would then contain a plain list of
either tiddlers themselves or tags which one wants to explicitly
either include or exclude, maybe with the following syntax:

TiddlerName
keep>TiddlerName
tagged>TagName
keep>tagged>TagName

So, before importing from a store you would have to parse this config
somewhat like this...

inc,ex,incTagged,exTagged=[];

stores=getConfigTiddlerSection.split('----');
for(store=0;store<stores.length;store++){
lines=stores[store].split('\n');
thestore=lines[0];
for(line=1;line<lines.length;lines++){
theline=lines[line];
keep=theline.substr(0,5).toLowerCase()=='keep>';
if(keep)theline=theline.substr(5,theline.length-5);
isTag=theline.substr(0,7).toLowerCase()=='tagged>';
if(isTag){
thetag=theline.substr(7,theline.length-7);
if(keep)incTagged.add(thetag);
else exTagged.add(thetag);
}else{
if(keep)inc.add(theline);
else ex.add(theline);
}
}
}

Now you have your arrays of tids and tags to be excluded or kept for
inclusion (overrides exclusion) and you can do with it what you want,
for example push it into some (global) array variable for later use.

some.config.path.includePluginFilters[thestore]={
inc:inc,
ex:ex,
incTagged:incTagged,
exTagged:exTagged
}

Then you can later check when importing the store, whether your
tiddler or its tags either is in the exclude or in the include array
for the store, whereas you would include a tid by default or do so
when it is in the include array or otherwise exclude it when only in
an exclude array but not in any include array.

You could also add a global include / exclude array under
some.config.path.includePluginFilters["__globals"];
which you could then apply to all included stores and not just a
particular one.

Mind you that the above code is a mere skeleton, neither tested nor
with sufficient variable declarations.

If you are really keen of providing the full deal, you could even
allow for filters like these...
field>somefield>contains>someContent
field>somefield>someOperator>comparativeValue
field>somefield>hasValue>true/false

of course also working like this:
keep>field>...

...and then also have subArrays like these:
incField, exField

With so many separators, however, I would probably split each line
like so:
def = theline.split("'>");

If you want to allow for someone to have ">" in a tiddlers title, then
you would have to use a different separator or simply make it longer,
like ">>". Or to be really flexible, define your separator as a
variable, then people can use whatever they want in their configs.

Hope that helped,

Cheers, Tobias.

[Tobias Beer]

Not to forget... my macro call would then look like this...

<<include fromwhere config:someConfigTiddler>>

[Yakov]

Right, thanks.

As for the design of the filters themselves, my idea is quite close to
the Tobias', but as for now I'd like to introduce 5 filters:

1. tiddlers to include // if this is not empty, the other filters are
applied to this set rather then to the whole set of tiddlers
2. necessary tags // include only those having this tags
3. unwanted tags // exclude those with these ones
4. unwanted tiddlers // exclude these ones too
5. additional tiddlers // add these after the filtering anyway

but for the usage I'd like to implement first only "2." is relevant.
The first usage I'm talking about is the sharing of tiddlers between
TiddlyWiki documents. Because I want to have some constraints which
will signal me not to break links between documents my idea is to add
a tag like "shared with: A" where A is a "name" of a document which
includes. In this case, when I'd like to change the name of the
included tiddler or delete it, at least I'll see the tag and do it
carefully. But this is rather a virtual constraint, and as I delete a
link in a incuding document, I should be careful anyway (in this
approach nothing will remind me that a tiddler is not in this
document).

***

As for the definition of the filters, there's quite simple way for it
-- use the bracketed lists. The value of the "exTags" variable will
look like

"tagName [[another tag name which contains spaces]]"

As we have the readBracketedList function in Strings.js [1], parsing
is as simple as

exTags = readTagsString.readBracketedList(true);

Now as for the place to define the filters, in the final version I'd
prefer have smth like

<<include
fromWhere
tiddlersToInclude:"..."
necessaryTags:"..."
tagsToExclude:"..."
tiddlersToExclude: "..."
tiddlersToAdd:"...">>

And some arguments can be substituted with the names of slices, if
necessary; but I can't see much use in separating the macros with
their parameters since they are usually used in the IncludeList
tiddler anyway. But here is a tricky thing: despite the fact that
usage of two <<include>> macros is rather unlikely, there should be at
least some notification if it happens.

There's another thing: as the system of the core filters evolves (and
ideally I'd like it to be extensible and separate the aggregation and
representation completely), I should really think of how to apply the
core mechanism here.

***

Now, back to the storage. Ok, so the simple version is a hybrid of
what Tobias and Mario suggested:

config.options.includePluginFilters[thestore]={
...: ...,
...: ...,
...
}

but here the tricky situatioin of few <<include>> tiddlers with the
same target applies: I should process it in a way that user didn't
imply (simple and keeps the user away from some mess) or make the
structure more complicated. I think the first one is the way to go.

Although, as I understand, SystemSettings can't be used in this case,
microplugin like those "zzConfig"s can be employed.

<<<
> Perhaps it's a good idea to set the "filters" as properties of
> hasToPushWhenIncluded itself, what do you think?

To be honest, I actually don't understand, what you try to do. May
be,
because I never wanted to use IncludePlugin or similar. Or, I'm just
to lazy to think about it ;)
<<<

Well, as I understand, in js every function is an object, so I thought
perhaps it would be a good idea to attach the "filters" to the
function which filters itself
(aStore.hasToPushWhenIncluded.includePluginFilters) rather than make
some object in config.options.

***

So, the issues are:

1) config.options.includePluginFilters[aStore] or
aStore.hasToPushWhenIncluded.includePluginFilters ?
2) how (is it possible) to use core filters here?
and also I need to learn the macros' params handling (ok, I know the
locations of most of the documentation [2], [3], [4], [5], [6], [7],
but if there's something else, feel free to add).

[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Strings.js
[2] http://oldwiki.tiddlywiki.org/wiki/Dev:Macros / not migrated yet
[3] http://oldwiki.tiddlywiki.org/wiki/Dev:Custom_Macros / not
migrated yet
[4] http://helloworld.tiddlyspace.com/#HelloWorldButtonPlugin
[5] http://helloworld.tiddlyspace.com/#HelloWorldNamedParamsPlugin
[6] http://helloworld.tiddlyspace.com/#HelloWorldManyParamsPlugin
[7] http://groups.google.com/group/tiddlywiki/browse_thread/thread/420f9c8f19c80a25