Making more editions - how?

[Mat]

@Jeremy

Inspired by Jeds Résumé edition, I'm thinking I too should attempt to make something that might hopefully become as good and accepted as an edition. For ideas of what I have in mind, see Appetizer TW's

1)  Elsewhere you've mentioned that an edition should best avoid plugins that are not in standard distro or they'd have to be included in the plugin library too.
1a) ...but I take it that all plugins, themes etc that are on tiddlywiki.com can be included without a problem, right? (I don't have any one particular in mind, it's just a general question.)
1b) Are there other such technical conditions/preferences?

2) I have a particular type of list with items in mind. These items are to be tiddlers and display some common data. I could put all this data in the text field but the data consists of several discrete types of data. I will also want the user to easily create new items. To me it seems that fields would be an ideal solution for this, including presenting them as a kind of //form// when a user is to create a new item. But I note that fields are not searched, neither the field names nor the filed values (!?) So...
2a) What would be a better way than splitting the data into fields?
2b) Altenatively, is there a good way to make fields show in search? Ideally not all fields, only the ones I specify.

Thank you Jeremy!

<:-)

[Tobias Beer]

Hi Mat,

 

1)  Elsewhere you've mentioned that an edition should best avoid plugins that are not in standard distro or they'd have to be included in the plugin library too.

I don't think that's true, and if at all, only when it comes to editions in the core repo.

 

1a) ...but I take it that all plugins, themes etc that are on tiddlywiki.com can be included without a problem, right? (I don't have any one particular in mind, it's just a general question.)

Depends on what the edition does. I don't think there is any guarantee that you can add whatever you want, even from the core plugins / themes / editions. Things can always break... and all that can break is never tested.

 

1b) Are there other such technical conditions/preferences?

It really boils down to trial and error. 

 

2b) Altenatively, is there a good way to make fields show in search? Ideally not all fields, only the ones I specify.

There is this ...which has been lingering about for a while now... 

#1386 extended search filter

https://github.com/Jermolene/TiddlyWiki5/pull/1386

...and not been touched again because the architectural foundation in terms of "tiddlermodules" appeared to be ...well, somewhat of concern but then again not what we wanted to use and so it came to a halt on a technical issue... that could have easily been reworked / refactored later, if needed ...but wasn't. I do understand that we want a well designed architecture in the core... but if what we have or even things on the wishlist prevent major improvements (like this) from getting underway... then we're not quite doing it right, imho.

Best wishes,

Tobias.

[Jed Carty]

1) If an edition is going to be listed as part of the core repo Jeremy said that any plugins either need to already be on tiddlywiki.com or added to it. Past that I think that the only requirement is that it works. Being useful would help too.

2) If you have a set list of fields than you could use the search operator. something like:

[search{transcluded search term}][search:field1{transcluded search term}][search:field2{transcluded search term}]

where your search input is put into a temporary tiddler used for the transcluded search term portion. If you want something that will take less updating if you change the fields used than put the fields you want to search in a list field of some settings tiddler and then use something like this:

\define thisSearchResult()
<$list filter='[search:$(CurrentField)${transcluded search term}]'>

</$list>
\end

<$list filter='[list[reference to list field]]' variable=CurrentField>
<<thisSearchResult>>
</$list>

Using that you couldn't sort the entire output list without using some more advanced things. I think Tobias made a plugin that would let you do it and the way I made my version of breadcrumbs would probably let you do it.

[Mat]

Tobias, thanks for your input.

Regarding questin 1, I figure that in the end Jeremy is the decision maker for what makes it as an official edition on tiddlywiki.com, so I'd better have it straight from him when it comes to what is allowed or preferred. Your input does make sense though.

2b) Altenatively, is there a good way to make fields show in search? Ideally not all fields, only the ones I specify.

There is this ...which has been lingering about for a while now... 

#1386 extended search filter

https://github.com/Jermolene/TiddlyWiki5/pull/1386

That thread dives techy pretty quickly but if I understand a main point, it's to be able to categorize fields. I don't have to tell you what my wish is in that matter, but a less pretty solution, to be able to search groups of fields, might be to group fields by naming them with pre- or suffixes. And I know how you feel about this, but it would at least work (I think).


Definitely off topic, but:

but if what we have or even things on the wishlist prevent major improvements (like this) from getting underway... then we're not quite doing it right, imho.

Have you ever considered a fork? Not to step away but to run a parallel experiment where you - and we all - can find out that "ok, that was not a good idea" OR "now that is just superior!" - both findings are of value for the TW project at large. Big value even, considering how fundamental some of your ideas are.
Just a friendly thought.

<:-)

[Mat]

Jed wrote:

1) [...good points about criteria...] Being useful would help too.

;-)

 

2) [...search fields...]

Thank you, great to know. I'll get to this so I'll try it out then.


<:-)
 

[Tobias Beer]

Hi Mat,

 

Have you ever considered a fork? Not to step away but to run a parallel experiment where you - and we all - can find out that "ok, that was not a good idea" OR "now that is just superior!" - both findings are of value for the TW project at large. Big value even, considering how fundamental some of your ideas are.
Just a friendly thought.

I have really not and I think it isn't a good idea. I'd rather focus on plugins and helping improve the core, even if that means that a lot of stuff won't get accepted... reasons be reasons.

Best wishes,

Tobias.

[Tobias Beer]

Hi Mat and Jed,

 

2) If you have a set list of fields than you could use the search operator. something like: 

[search{transcluded search term}][search:field1{transcluded search term}][search:field2{transcluded search term}]

Take a look at:

Search Multiple Fields With A Subfilter @ tobibeer/plugins

Best wishes,

Tobias. 

[Mat]

Niiiice!!! :-D This is so exciting for me (ref. my new found interest in active use of fields).

Now, I can't fully follow the syntax - e.g how does the placeholder %inputTitle% know the the term inutTitle? Is this a hardcoded keyword?

...but, more importantly for the OP, I'm wondering this also search the field name itself, or only the field value? The descriptions don't make this clear and even the last example that I interpret as possibly dealing with exactl this question is described like:

"This example returns the actual fields where the search term could be found for the fields title, tags, summary and doesnt-exist:

Does "found for the fields" mean "found in the field values for..." or perhaps both "found in the field titles and/or the field values for..."

As you know, normal search does search both the tiddler titles and the text fields - and even top-ranks title hits - so it would be very good if this was also the case with your method!

Oooh, this is so exciting! A much more active use of fields really feels like it's opening up a lot of possibilities. I'm sure experienced TW coders reading this are thinking "but we've been able to do this forever"... but that is precisely because they're experienced TW coders.


@anyone - Apropo use of fields; it seems like a perfect method to use for forms, i.e the type of "fill in the empty boxes" that laymen are used to. I think it would be easy to make such a form, using a field per "empty box", but does anyone know if it's already been made by someone, in TW?


<:-)

[Jed Carty]

I am not sure what your last question means. You may be interested in looking at the tiddlertool I made to see how I dealt with searching for field names as a reference. Also for forms do you mean something like this?

[Tobias Beer]

Hi Mat,

 

Now, I can't fully follow the syntax - e.g how does the placeholder %inputTitle% know the the term inputTitle? Is this a hardcoded keyword?

Yes, and it's a variable that is set to each input title in turn when the subfilter is evaluated against it ...unless you'd declare a custom variable in the suffix like so:

a b c +[filter: var:foo<some-subfilter>]

..then this variable foo will be set instead ...first to a, then to b and finally to c. 

...but, more importantly for the OP, I'm wondering this also search the field name itself, or only the field value?

There is no filter yet that matches some substring of a field, yet.

I think the has filter operator can and should be amended to cater for basic wildcards, e.g.:

• has:prefix-*[]
  
• has:*-suffix[] 

Does "found for the fields" mean "found in the field values for..." or perhaps both "found in the field titles and/or the field values for..."

It means "in the field value" ...not the field names.

The field-names simply specify in which fields to search

not which field-names to search for.

 

As you know, normal search does search both the tiddler titles and the text fields - and even top-ranks title hits - so it would be very good if this was also the case with your method!

You can always construct cascaded filters where one field gets added first and some other(s) later.

 

Best wishes,

Tobias.