Posted in: SPARK UI Toolkit Controls
Stu LeibowitzMay 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 KolbanMay 13, 2016 at 7:50 am #1770
If one looks on the excellent documentation page for “Table” seen here:
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 KolbanMay 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 BorenMay 13, 2016 at 3:03 pm #1789
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.
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.
Rackley BorenStu LeibowitzMay 15, 2016 at 7:38 pm #1797
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 ChastangMay 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 BorenMay 20, 2016 at 3:20 pm #1826
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.
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.
Rackley BorenStuart JonesMay 23, 2016 at 2:25 pm #1868
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?
ThanksRackley BorenMay 23, 2016 at 5:21 pm #1869
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.
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…
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.
Rackley BorenStuart JonesMay 23, 2016 at 6:39 pm #1872
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.
ThanksRackley BorenMay 23, 2016 at 6:50 pm #1873
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.
RackleyStuart JonesMay 23, 2016 at 7:15 pm #1875
For the record, I attached the BO that I have been using – the one that has caused me such issues with search.Rackley BorenMay 23, 2016 at 7:17 pm #1877
I apparently hit delete when trying to open it… Sorry about that… Could you please attach again?Stuart JonesMay 23, 2016 at 8:25 pm #1878
reattaching…Rackley BorenMay 24, 2016 at 2:40 pm #1893
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.
You must be logged in to reply to this topic.