Search for Table

Stu Leibowitz

May 12, 2016 at 9:35 pm #1762

Is there an easy way to configure a global search for data in the table?  I’ve seen other table controls that have a “show search” configuration option.  This adds a search text box that gives the user a global search of all columns and rows in the table.  The search filters the table entries to only  the “hits.”  This should be achieved simply by selecting the configuration option that causes the search box to be displayed.  Then the search should “just work” without additional scripting.

In general, it is always great when Coach Views hide complexity from the average process authors.  (The Modal Section is another example where much of the complexity could be hidden inside the implementation of the Coach View.)

Neil Kolban

May 13, 2016 at 7:50 am #1770

If one looks on the excellent documentation page for “Table” seen here:

https://salientprocess.zendesk.com/hc/en-us/articles/206521927-Table

One sees a whole configuration section on “Searching” … but when I look in the actual toolkit, I’m not seeing that option.  I wonder if it got “lost” in the Client Side migration?

 

Neil Kolban

May 13, 2016 at 8:58 am #1775

Later … I came across this video which seems to show a really powerful technique for searching and filtering:

 

Rackley Boren

May 13, 2016 at 3:03 pm #1789

Stu,

I did not immediately reply last night as I wanted to look into some more options regarding global search on the table. Looking at the methods available to us in the Table JS Doc, I do not see an option for a global search in the table. We have methods for searching, but you pass the column name to it.

This lead me to do a little thinking about what value is gained out of every row being searched on when the user really just wants to search through the state column as in the video example put together by our team.  In a global search, you will have a lot of results being returned that are not relevant because the phrase you entered matches instead of narrowing down what you are really after.

As far as a config option to enable this where the search will “just work” without scripting… The scripting to make this happen is minimal. A line of JavaScript that is placed in the “On Input” event for a Text control as described in the video Neil linked.

${TableControlId}.search([columnIndex],potential,true, true);

 

Neil,

I am looking into the reasoning behind the Searching configuration option was removed. I will have to get back to you on it as I did not see any note of it in the release notes. We will likely need to just update the KB article to reflect the change on the Table control to resolve this.

 

Regards,

Rackley Boren

Stu Leibowitz

May 15, 2016 at 7:38 pm #1797

Rackley,

Thanks for your response.  I do think the are use cases for the global search in a table.  In many cases it can save the user time when he does not know which column to search.  This is the way IBM has implemented the search for the task list in the default portal interface.  I can look for a string no matter which column it appears in or even if the particular row is not currently being displayed.  Yes, there’s a chance that many rows will be returned.  But there’s also a chance it will be just what the user is looking for.  Since this is the way the task list works and the way our other partner’s control works, I would suggest this as a feature request.

Cindy Chastang

May 18, 2016 at 8:31 am #1814

I was just coming to the forum to see if anyone had asked about the missing search options in the table configuration.    Just thought I’d chime in to say I saw them in the article and not in the toolkit (4.3.3 EE).

Thanks to Neil for posting that video – I will definitely check that out as it sounds like it may have what I need and I hadn’t found it yet..

Rackley Boren

May 20, 2016 at 3:20 pm #1826

Stu,

When I am wrong, I am wrong. Sorry about that. I got a little philosophical thinking about it late at night and it bled into my response. Anyway I reached out to ask about this and apparently global search was already implemented a little while back, it just did not make it to the JSDoc.

To implement global search follow the steps in the video, the only difference is that you pass null into the value for the columns.  Take a look at my screenshot.

Again, not a check box to do it, but only addition of one control and a line of JavaScript. You end up with much greater flexibility this way as you can more tightly control the search, make it available based on some other action, or various other combinations of SPARK controls.

 

Cindy/Neil,

The search related configuration options were removed because they were giving the false impression that you could enable/disable the search functionality of the table control. These were configuration options that were initially going to have some purpose, but did not end up getting used and were not promptly removed.  We will get the KB article updated to prevent any further confusion.

The search capabilities for the Table and Service Data Table are always “on” since they have a method that allows for this. The video Neil linked is a great example of how to.

 

Regards,

Rackley Boren

Stuart Jones

May 23, 2016 at 2:25 pm #1868

Hello,

Like the others posting to this thread, I was very interested in this capability. I tried it out with an existing coach that I had built and it didn’t work. Disappointed, I built myself a brand new, very simple coach and it worked just fine so I decided to try narrowing down my issue. This is what I have found so far:

• If I bind a simple list (each field in the list is a simple type) to my table then everything seems to work very well indeed.
• If I bind a more complex list to my table (fields in the list are themselves complex types) then the table search doesn’t work at all.

Is this a known issue? Is there some workaround? Have I built my coach incorrectly for this type of capability to work?

Thanks

Rackley Boren

May 23, 2016 at 5:21 pm #1869

Folks,

For anyone hopping into this thread. Let’s make sure we are clear here… the simple list Stuart is referring to above is NOT a list of simple types, such as a list of String. It is a known issue that the Table control cannot be bound to these.

Stuart,

I set up an example table that is bound to a list of type Person, that is made up of simple types, but also has a complex type as one parameter. In this case currentAddress is also a complex type Address. Both are defined below…

Person

name (String)
email (String)
phone (String)
currentAddress (Address)

Address

line1 (String)
line2 (String)
city (String)
state (String)
zip (String)
country (String)

Following the same steps in the previously mentioned material, I can set up a search that allows me to search through the simple types in the Person list like name, email, phone, etc, but it does not allow me to search on things like city, state, zip which are part of my address object. I have attached a screenshot of the table setup.

I believe this is the issue you are running into. Though for yours, everything is a complex type so it appears that search does not work at all. Given this and what I have poked around with in the SPARK code, I would say that searching on complex objects in a column is unsupported at this time.

I will pass the feedback that you are interested in the ability to search on columns containing complex types to the SPARK team. They might be able to point me to something that I am missing. I will update this thread when I hear something one way or the other.
Regards,

Rackley Boren

Stuart Jones

May 23, 2016 at 6:39 pm #1872

Hello Rackley,

You’re spot on! As you say, in my example, everything in my business object is made up of complex types. I am building a ‘flat’ table, unlike the diagram above, but everything that is in my table is at the end of a chain of complex types. Now that I know that this restriction exists, I can restructure my BO so that I can enable searching.

I do consider this to be a little restrictive. In my experience, nested BOs are the pretty common and I was surprised that this isn’t supported. For the time being, it is fine with me that this restriction is understood, but I’d like to see this addressed at some point.

Thanks

Rackley Boren

May 23, 2016 at 6:50 pm #1873

Stuart,

Based on your description, I thought you had your table set up closer to what the address looks like in my example. Since that is not the case, I just checked myself and I am surprised that the flattened out structure of my table (See attached) did not work. I have a query out to the team as mentioned above. I will updated it with this info, as I was expecting it to work because I agree the nested BOs are very common. Person being a great example.

I will update you based on what I hear back.

 

Regards,

Rackley

Stuart Jones

May 23, 2016 at 7:15 pm #1875

Hello Rackley,

For the record, I attached the BO that I have been using – the one that has caused me such issues with search.

Rackley Boren

May 23, 2016 at 7:17 pm #1877

Stuart,

I apparently hit delete when trying to open it… Sorry about that… Could you please attach again?

Stuart Jones

May 23, 2016 at 8:25 pm #1878

reattaching…

Rackley Boren

May 24, 2016 at 2:40 pm #1893

Ok Folks,

 

We did some talking internally and I will be filing an enhancement request for this. The underlying issue is the same for both of them. The way the search function works is that it takes whatever is in the column and creates its string representation. This results in [object Object] for none string/number/boolean values, which can’t be evaluated by a match function.

I am going to close and sticky this post later so everyone is aware of the limitation. I do not have a specific date that this will be completed to announce at this time.

 

Regards,

 

Rackley