This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DEVELOPERS FORUM - Dynamically show/hide columns in the main search grid

jeffla376 - Thursday, August 25, 2011 1:33 PM:

Has anyone written any code that dynamically shows and hides columns in the main search grid? We want to be able to dynamically shows part parameters on a per classification when classification is chosen from a drop-down list.

We want to create a decent way to search an electronic component database. In the main search grid, all columns (part properties) are visible. We created a drop list that mimics the classification values to allow us to quickly narrow a search to a specific component type (e. g. capacitor). To make this usable, we need to filter out all of the columns except the ones that contain property values for capacitors.

Thanks!

Jeff Lavin



Brian - Friday, August 26, 2011 7:59 AM:

Hi Jeff,

I think trying to do that from the main search grid is going to be difficult.

You don't have enough control over what is being passed to the server in terms of the query so you can't intercept the query beforehand to get the "filter" for the properties.

I would build a new page (either a form or external HTML page) and call it from an action.

On the form I would put fields to allow you to specify the search parameters especially the classification parameter you are using.

Then you can retrieve only the fields that you want to display and dynamically build the grid to have the fields that you want.

Have a look at the "Changes.html" page under  /client/solutions/PLM/Scripts/Changes under your Innovator install. This will give you an idea of how to build the XML for the grid and how to load the grid with your results.

Hope this helps.

Brian.



eric_h - Friday, August 26, 2011 12:58 PM:

Thanks Brian.

I am working with Jeff on this. Can you point me to where I can find the 'Changes.html' script in action?

On a related note, let me give you some thinking I had about altering the 'Simple' search script. I did some testing of this based on cloning the 'out of box' version and altering it (on a side-note, I had to rename the original to something like 'Simple-original' because there is code that depends on the name of the script itself; you cannot just clone 'Simple' and modify as say 'Simple-new' - it will not work since code depends on the search name being called 'Simple'.)

What I did was create a list that I called 'part_type' that was basically all the values of part classifications that have been created. I can label each entry whatever I want, but the values need to match the string as stored in the classification field. I have not created this yet (have been hand-synching) but what I would like to do is have a server method triggered 'onBeforeAdd' and 'onBeforeUpdate' that copies the value of 'classification' to 'part_type'. The reason for the list is to allow a drop-down chooser for part type vs. needing to do wildcard type string searches on the classification value. It just makes sense to have a drop-down list used to filter the part class in a search.

As far as being able to dynamically show/hide property columns based on the assigned class path for each, I did some testing of the 'IGridComIncoming.SetColumnVisible' method to see if this might provide some options. It turns out that this method does not add and/or remove the columns from the grid, it just shows and hides them, not much different than what you do when you right click on a column header and choose to hide or display hidden columns.

So the idea I had was to load all property columns not set to 'Hidden', and the use some XPath and JavaScript to hide all columns that have an assigned class path then display those that matched the 'part_type' (and therefore 'classification') value. When the drop-down list value changed, I would tie that to an event (it might have to be a custom JavaScript event) that would call a function (maybe the same triggered on grid load) that hid all of the class path properties and then showed those belonging to the newly chosen classification.

Does this make any sense? Any thoughts on this kind of approach? It would be nice to keep the simplicity of the default search engine available instead of trying to create an alternate grid. That said, I'd like to see 'Changes.html' in action and see what it looks like.

Thanks,

Eric



Brian - Friday, August 26, 2011 6:24 PM:

Hi Eric,

The changes.html page is loaded in the "Part Changes" relationship type for a Part.

Which file are you editing/searching to find the "simple" search script?

I tend to shy away from editing something as "core" to the system as the main search grid since it is used everywhere and changes are hard to test against all scenarios. This is why I suggested a separate page. That way you get to control exactly what is happening and limit its reach to only the Items that can call that Action.

Using your own page you could:
If you have your drop down filter to match the classification then you can set your query to retrieve only the fields that you need and set the grid up appropriately. On setting the filter you could retrieve the property names that belong to that filter and allow the user to enter search criteria against these before the main query is sent.

With the Main search grid:
To get "other" columns to show in the main grid I think you would have to set the "hidden" property to "0" for the columns you want to show and then let the normal search grid take care of it. This would require that your code has permission to edit the Item Type. I can see that this could cause problems with more than one person using the search at a time. If you don't do it this way then you are introducing special handling for one Item Type in the search grid that may cause unexpected issues later and may cause you problems when you come to upgrade the system later.

Maybe even create a "Part Search Page" similar to the "Search Centre" page used for Documents in a couple of community solutions. If you did this as a form and named this "Design" then it would be the page that loads when you click on the Design TOC header.

Cheers,

Brian.



eric_h - Friday, August 26, 2011 6:37 PM:

Thanks Brian. I'll take a closer look at what you said later, but wanted to reply while I was still here. The search code for each search type is actually stored as a DB row entry in the 'Search' table. So in fact each search type is an instance of 'Search'. The 'out of box' code depends on the search name being a certain given value for the default search types. Basically there is a JavaScript file that gets loaded with these searches that has functions that only apply to certain search types determined by assigned name. I understand the risk of changing this code, so that is why I have cloned the simple search and renamed the original (new version has to be named 'Simple' - BTW, I can access the search modes via Aras by making the Search table viewable in the TOC for administrators) as a backup when I tested some stuff in the past. Anyway, it was good to at least dig into the code a bit.

There is the possibility of writing a sort of 'onLoad' JavaScript function that triggers hiding any of the columns that have a class path assigned (determined via XPath query), then showing only those whose class path matches the current classification/part_type chosen. This same method could be triggered any time the drop-down list value changes. I would tie this function only to item types that needed this sort of thing. This is all in theory how I would do it. Whether it is doable is still to be determined (I would try on a test server if I decided to even give it an attempt.)

Anyway, I am going to take a close look at some of your suggestions you have mentioned and see what I can figure. I'll let you know if we have any success. Thanks for the help.

Eric

 

 



fli - Thursday, January 9, 2014 8:37 AM:

Hi, 

Yet another interesting thread, thanks for sharing :-)

 

Did you succeed in archiving the wanted functionality and/ or were you able to come to a conclusion on this matter?
Br Christoffer

 



pankaj - Monday, June 9, 2014 6:32 AM:

Hi Guys,

Are you still facing this issue. I have a solution for this. If anyone is interested to know i can share my ideas.

 

Regards,

Pankaj B



fli - Tuesday, June 10, 2014 4:51 AM:

Hi Pankaj,

 

I am very interested, please share your solution and idears.

 

- Christoffer



pankaj - Wednesday, June 18, 2014 1:59 AM:

Hi Christoffer,

I have made the changes in Core file for hiding/showing the columns in MainGrid. i.e., in ItemsGrid.html
Below code you have to add in end of this function "onReinitialize".
if(itemTypeName=="part")
{
    for (var inx =0; inx <visiblePropNds.length; inx++)
    {                   
        var propNm = arasObj.getItemProperty(visiblePropNds[inx], "name");
        if(propNm!="created_by_id" || propNm!="classification")// Only this two properties will be visible in Main Grid
        {
            var idx=inx+1;
            grid.SetColumnVisible(idx, false, 0);
        }
    }
}

Regards,
Pankaj B