[TW5] Combobox

[Hegart Dmishiv]

Hi all,

I have finally mastered the <$select> widget, but it has left me wanting a <$combobox> widget as well. In my latest experiment for our {{DesignWrite}} semester project, TiddlyCRM, I've been able to populate the options of a <$select> widget from a series of tiddlers which are all tagged  foobar . This works great! However, what if the option I want is not currently listed, and I want to add it? That is where a <$combobox> widget or equivalent would come in handy. Ideally, I'd like to be able to do this without having to add a plugin, if possible. If not, could someone point me to something that would achieve this result? I know we have the original inventor of the combobox itself, lurking around here somewhere, hehe.

Here's my current code for the <$select> widget I'm using...

<$select tiddler="$:/_Temp/foobar" field="city" default="Foo">
<$list filter="[tag[foobar]]">
<option value={{!!city}}><$view field="city"/></option>
</$list>
</$select>

Note that this solution presumes that every tiddler in the filtered list will have a city field, and it doesn't currently check for uniqueness of the options.


Hegart.

[Eric Shulman]

On Sunday, April 3, 2016 at 3:40:11 AM UTC-7, Hegart Dmishiv wrote:

Hi all,

I have finally mastered the <$select> widget, but it has left me wanting a <$combobox> widget as well.....I know we have the original inventor of the combobox itself, lurking around here somewhere, hehe.

Ok.... here's my ComboBox macro.... (note: this is NOT officially published yet, and is subject to change without regard to backward-compatibility.

http://tiddlytools.github.io/InsideTW/empty.html#TiddlyTools%2FMacros%2Fcombobox

and here's some (preliminary) documentation:

http://tiddlytools.github.io/InsideTW/empty.html#TiddlyTools%2FMacros%2Fcombobox%2Finfo

The combo box appears as a basic text input field, except that when you mouse over it, a down arrow button appears, allowing you to display a list of items to select from (using a filter you specify as a macro parameter).  Depending upon optional parameters, you can have the list also appear as soon as you begin to type into the input field, and also have the list progressively filtered to only items that 'match' the current input value.

In addition to the basic edit/list combination, the macro also permits you to specify an "okaction" parameter (see examples) that performs action(s) based on the contents of the input field.  When an okaction is provided, mousing over the input field shows ok and cancel buttons in addition to the down arrow button.

enjoy,

-e

Eric Shulman

TiddlyTools / ELS Design Studios

InsideTiddlyWiki: The Missing Manuals

Note: the URLs above (as well as the URLs contained in the documentation itself) are not the final location for these tiddlers, and *WILL* change when published (hopefully very soon).

[Hegart Dmishiv]

Wow, thanks Eric! That looks exactly like what I was hoping for!

I'd like to make use of your code in my project, if that's okay. I'm happy to credit you appropriately however you desire. My project will be released as an academic semester project for {{DesignWrite}} at first (Alpha Release), but once that's complete I would like to release it back to the wider TiddlyWiki community (Beta Release) for further development and refining, and then for use freely by community support organisations and private individuals here in New Zealand (Full Release). I understand that your code is not ready for distribution yet, but I'm sure that won't matter for the Alpha Release of TiddlyCRM, which is due in six weeks time. Beyond that I don't have a fixed schedule, and am happy to work in with your release schedule.

Kind regards,

Hegart.

[Hegart Dmishiv]

Hi Eric,

Here's what I've got so far, after just a few minutes of playing with your macro. It replicates my <$select> widget example above, but using your <<combobox>> macro instead...

<<combobox tiddler:"$:/_Temp/foobar" field:"city" filter:"[tag[foobar]]">>

What I'd like to know now is how to use the filter: parameter to specify only the unique values of the "city" field for each tiddler that is tagged as  foobar , and to ignore those tiddlers returned by the filter that don't contain a "city" field. How would I go about doing that?

Hegart.


On Sunday, 3 April 2016 23:09:47 UTC+12, Eric Shulman wrote:

[Hegart Dmishiv]

Hi again Eric,

Your LegalStatements tiddler advises that any modifications of your code should best be handled as a feature request. I haven't dug deep enough yet to be making such a request, but I thought it might be useful to know in advance if there is a GitHub repository for this macro, so that any issues can be raised there?

Hegart.

[Eric Shulman]

On Sunday, April 3, 2016 at 2:14:06 PM UTC-7, Hegart Dmishiv wrote:

Hi again Eric,

Your LegalStatements tiddler advises that any modifications of your code should best be handled as a feature request. I haven't dug deep enough yet to be making such a request, but I thought it might be useful to know in advance if there is a GitHub repository for this macro, so that any issues can be raised there?

Hegart.

As previously noted, I haven't officially published any of the stuff you are looking at.   I've been using a single-file TW5 configuration to develop and implement all my new TW5 add-ons, so there are no individual .tid files to commit to a repo.  The whole document *is* stored on github (at the URL I posted), so you could, in theory, make requests there.

However... the URL I provided is not intended as a general distribution point for the add-ons.  Instead, it's a working prototype for the TiddlyBook "edition" I am developing and simply uses the combobox macro as part of it's implementation, so I'd rather not have individual issues posted there.

I *am* building a new TiddlyTools document to officially publish my work, but there's still a few things I need to do before that will be ready.  This includes renaming and refactoring tiddlers, creating plugin "bundles", and generating separate .tid files (so they CAN be individually comitted and tracked in a github repo).

-e

[Hegart Dmishiv]

Thanks for the explanation, Eric. I'm really excited by what you've produced here. I've got a working example of it so far in my SampleData playground, here. I still need to overcome these issues with it though:

• To populate the options from any given field, not just the title field.
• To populate the options only with unique/distinct values from the given field.
• To ignore any options that do not contain the given field.

These are all probably more to do with my use case, rather than your macro though. Also, I look forward to later using the okaction: parameter to set the filter: parameter of a subequent <<combobox>> invocation using a filter stored in a tiddler field. I understand from previous advice you've given me on this subject, that I'll then need to use a <$macrocall> widget for that, rather than a <<macro>> invocation. I'll let you know how it goes. Happy to beta-test this for you! ;-)

Hegart.

[Eric Shulman]

On Sunday, April 3, 2016 at 3:15:49 PM UTC-7, Hegart Dmishiv wrote:

Thanks for the explanation, Eric. I'm really excited by what you've produced here. I've got a working example of it so far in my SampleData playground, here. I still need to overcome these issues with it though:

• To populate the options from any given field, not just the title field.

That is actually controlled by the "template" parameter (currently *undocumented*).  The default value is template="<<toc-caption>>", which shows the tiddler's caption text, with a fallback to the title if no caption is present.  You can use this param to show other fields, like this:

template="{{!!fieldname}}"

Note how the value is enclosed in quotes, so that the inner syntax is NOT parsed, but simply passed along to be used as the 'template' for outputting each list item.

• To populate the options only with unique/distinct values from the given field.

That can be controlled by the filter param.  You would need to use the each[] filter to get unique values. 

• To ignore any options that do not contain the given field.

Again, that is an aspect of the filter you specify.   

These are all probably more to do with my use case, rather than your macro though. Also, I look forward to later using the okaction: parameter to set the filter: parameter of a subequent <<combobox>> invocation using a filter stored in a tiddler field. I understand from previous advice you've given me on this subject, that I'll then need to use a <$macrocall> widget for that, rather than a <<macro>> invocation. I'll let you know how it goes. Happy to beta-test this for you! ;-)

Yes, exactly.  The $macrocall widget allows you to use variables and/or references as macro parameter values.   Thus, you could write something like:

<<combobox tiddler:"$:/_temp/currentfilter" filter:"[tag[something]]">>

<$macrocall name="combobox" tiddler="$:/_temp/target" filter={{$:/_temp/currentfilter}}/>

(above is untested)

give it a try and let me know how it goes...

-e

[Hegart Dmishiv]

That's awesome! I had to look up the each Operator to find out how to use it. It seems to have resolved both the uniqueness and the absence issues together, in one hit. Here's what I've got now in our main playground....

<<combobox tiddler:"$:/_Temp/foobar" field:"city" filter:"[tag[foobar]each:field[city]]" template:"{{!!city}}">>

This is working out great. Thanks! Once I get up to the stage of making the result of one combobox update the options of another, I'll let you know how we go with it.

Hegart.

[Hegart Dmishiv]

Hi Eric,

We've run into a little snag with the okaction parameter. We can't seem to get it to work, neither in your example in the documentation, nor in our own experimental tiddler. Any idea what's going on? This is something we'd really like to use, for all sorts of purposes in our TiddlyCRM project.

Thanks in advance for any advice you offer,

Hegart.

On Monday, 4 April 2016 10:49:15 UTC+12, Eric Shulman wrote:

[Eric Shulman]

On Wednesday, April 6, 2016 at 11:48:43 PM UTC-7, Hegart Dmishiv wrote:

We've run into a little snag with the goaction parameter. We can't seem to get it to work, neither in your example in the documentation, nor in our own experimental tiddler. Any idea what's going on? This is something we'd really like to use, for all sorts of purposes in our TiddlyCRM project.

If you specify field:"text" in the macro call, it works.

Originally, the macro had a default field name of "text" automatically assigned as a fallback.  However, this prevented the underlying $edit-text widget from being able to handle set of values in data tiddlers (using index:"..."), because the field:"..." param takes precedence if not left blank.

Note: the documentation was also incorrect in using the "list" param, which was renamed "filter" (but you apparently found that on your own, since your experiment is correctly using filter:"..."

Also... although you correctly used the "okaction" param in your experiment, in your posting here, you called it "goaction".  I just want to make sure others reading this don't get confused by the mistaken param name in the message.  Also note that, separate from the "okaction" is an optional (and currently undocumented) "clickaction" param, which allows you to extend the default action that occurs when you click an item in the list (i.e., in addition to setting the clicked item value into the edit-text field, you can have other "side-effect" actions performed when the item is clicked).

enjoy,

-e

[Hegart Dmishiv]

Hi Eric,

Thanks for the quick reply. I've corrected my mistake on the parameter name now, sorry about that. It's not the first time I'm made that same mistake now, haha.

Your solution works perfectly, thanks for that.

Hegart.

[Hegart Dmishiv]

Hi Eric,

I'm making a start on that idea of cascading the selection from one <<combobox>> into the filter for the options of another. However, in the second example on this experiment tiddler, I'm stuck with a bit of a problem. Despite having specified field:"city" as the field from which the option value should be stored, it still seems to be storing the title of the selected option, rather than the city. The option labels are being populated properly, using your example above of template:"{{!!city}}", but the option values aren't respecting the field: parameter.

Thanks in advance,

Hegart.


On Thursday, 7 April 2016 19:34:41 UTC+12, Eric Shulman wrote:

[Eric Shulman]

On Thursday, April 7, 2016 at 8:18:59 AM UTC-7, Hegart Dmishiv wrote:

I'm making a start on that idea of cascading the selection from one <<combobox>> into the filter for the options of another. However, in the second example on this experiment tiddler, I'm stuck with a bit of a problem. Despite having specified field:"city" as the field from which the option value should be stored, it still seems to be storing the title of the selected option, rather than the city. The option labels are being populated properly, using your example above of template:"{{!!city}}", but the option values aren't respecting the field: parameter.

The built-in (hardcoded) combobox list "click" handler performs this action:

<$action-setfield $tiddler="""$tiddler$""" $field="""$field$""" $index="""$index$""" $value=<<currentTiddler>>/>

i.e., when you click a list item, it sets the target field (or index) to the <<currentTiddler>> value (which is the title of the selected tiddler).

To set a different value when an item is clicked, you can specify a custom "clickaction" param in the macro call so that after the current title value is set, you can overwrite it with the value from the desired field instead.

First, to avoid nested use of """, define the click action as a separate macro:

\define myaction() 

<$action-setfield $tiddler="""$tiddler$""" $field="""$field$""" $index="""$index$""" $value={{!!fieldname}}/>

\end

Note that this macro is performing the same handling as the built-in click handler, but sets the value from a specified field, rather than using <<currentTiddler>>.

Then, to use this "action macro", add this param to your combobox macro call:

clickaction:"""<<myaction>>"""

Note the use of the tripled-quotes so that the call to <<myaction>> is NOT parsed, but is simply passed as literal text that is inserted into the combobox code and only invoked when an item is actually clicked upon.

let me know how is goes...

enjoy,

-e

[David Gifford]

Are you linking to a TW that has other people's home addresses? Do you have their permission to do that?

Dave

[Hegart Dmishiv]

Hi David,

I'm so glad you asked that question, it makes me feel a real sense of achievement! The SampleData which I've been working on is pseudo-random. I took the top twenty New Zealand surnames and the top baby names (male and female) in NZ from Dept. Int. Affairs (public spreadsheet), and randomised them together to generate realistic-looking  Person  entity names. Then I took the names of NZ's four largest cities, (Auckland, Wellington, Christchurch, Dunedin), and found a random selection of suburbs in each, and a random selection of well-known street names in those suburbs, then added a random number for a street number (with random pre/suffixes), and randomised the whole thing together to make realistic-looking random  Address  entities. The whole thing has been assembled together in our SampleData spreadsheet. I'm quite proud of the results, they're very realistic and I'm very happy to have fooled you into thinking they are real! So thanks for the compliment. ;-)

Hegart.


PS. The face images are all random too, using Morphases.com, Monoface, and Gombinoscope, all of which will ultimately be attributed in our project.

[Hegart Dmishiv]

Hi Eric,

I'm still not having much success with this. Would you mind having a look at my experimental code again, and telling me where I'm going wrong? I have your new <<myaction>> macro (I haven't even bothered renaming it yet) at the top of that tiddler, and I've specified {{!!city}} as the field which I want to be saving from. I've tried both a <<combobox>> invocation and a <$macrocall> widget, but I just can't seem to get it to work. The <<combobox>> seems to break something whenever I use...

clickaction:"""<<myaction>>"""

Also, I'm a little concerned about using the clickaction parameter for this. I had intended to use the clickaction param for something else, such as to modify the options of a subsequent <<combobox>> based on the selection from the current one. If I'm already using clickaction to set the value to be a specific field, will that preclude me from using it for other purposes as well? Or, will those other purposes just end up getting appended to the <<myaction>> macro?

Kind regards,

Hegart.

[HansWobbe]

At the risk of creating a digression that is tangential at best ...

It's always interesting to see peoples views on Permissions & Privacy since they vary in so many radical ways and always lead to controversial interpretations.  For example, Western societies generally recognize Name + (residential) Address = Identity.  However, Names (especially First and Last name segments) are freely available.  Similarly, (municipal) Addresses are legally considered to be "owned by" the City that assigns them, but are "in the Public domain by virtue of the fact that they are freely available and must be accessible.  That being said, it seems to be the combination of Name + Address ( = Identity ) that evokes Privacy concerns.

Amusingly though, tests have shown that no one seems concerned about Privacy when Name + (residential) latitude & longitude are associated.  This strikes me as strange given the ubiquitous availability of GPS data and its current resolutions.

I guess the expectations of Privacy rights and the need for Permissions to associate data elements, in this day and age of "Big Data", are still quite controversial.

"Very interesting" (said in my best German accent, whilst (vainly) hiding behind a potted fern ( as first seen in "Laugh In" ).

[Hegart Dmishiv]

Hi Hans,

Interesting discussion point. I can't say I've ever seen, nor even considered, a situation where Name + GeoLat + GeoLon = Identity. I have thought of adding geolocation to TiddlyCRM, naturally, as it is a common feature in other, big-name CRMs, but I wouldn't conceive of it becoming part of the "primary key" for an individual. We've been debating about primary keys lately within the TiddlyCRM team, with the possibility of using a UUID instead of Surname + Firstname, but we've settled for now on the latter. We may still change to UUIDs in the future though.

Hegart.

[HansWobbe]

Hegart ...

Having done a bit of research on this topic over several years, my own plans are design systems for the use of PlaceOfBirth and TimeOfBirth as a composite unique key.  There are deep historical reasons ( e.g. Inheritance by first born ) that result in even identical twins who are born at the same time, being "timestamped" one minute apart.  Furthermore, GPS resolution at 18" is now good enough that adjacent beds in the same maternity ward can be uniquely resolved. Moving forward, it will be increasingly rare for someone to not know their precise ToB.PoB.  Then, given the ease with which "official" documents can be joined to such a key, it will be possible to construct further unique keys that are applicable to each and every particular context.

Interestingly, TiddlyWiki's superb Tag support makes it possible to hash such keys using a character set (alphabet) of the more than 100,000 characters defined in the Universal Character Set or the 2*31 codepoints that are currently allowed for.  In effect, it is possible to come up with a unique hashTag for each and every person in as little as 2 characters.

As for UUIDs, I'm rather leaning towards the use of the cell phone SIM ID and the MAC ID as keys that will access any and all phones.  This is baed on the assumption that everyone will inevitably have one ( even if they are not "implanted" immediately at birth ).

My apologies if this sounds extreme, but it's such a long-standing interest for me, that I often find myself talking about it to the point of boring others.

Cheers,
Hans

[Dave]

Hi Hegart,

I was wondering if you had the time, would you mind explaining how you got your combobox (e.g. on the "View by person" tiddler) in your TiddlyCRM

https://www.google.com/url?q=https%3A%2F%2Fdl.dropboxusercontent.com%2Fs%2Fodu3my97ujyxz4h%2FSampleData-testing.html%23Add%2520Person&sa=D&sntz=1&usg=AFQjCNH6ZFPAD9u8l6fOQJSkQJnObXtmug

to work.  Out of all the links in this thread that's the only one that actively filters down all the existing options as you type.  I couldn't get the examples on Eric's site (presumably where you got the macro from) to work at all (unless I'm totally misuderstanding what its supposed to do)

When you go to edit the tiddler to see your code there's nothing there, so you must be doing some higher level TiddlyFoo than I can currently comprehend.

Thanks,
Dave