Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X
I am trying to setup Tree Grid Advance Widget in custom mashup to show part structure. I am using service (POST /Parts('{PartId}')/PTC.ProdMgmt.GetPartStructure) which returns single level children. When i bind the data to the tree grid it show the child parts list. I looked into help center but couldn't figure out. What i understood you need to bind data to "data" and "Child Data" along with some configuration. I have looked at the grid advance examples also but still cant figure out how to use it. The examples use a lot of java scripting to generate tree grid. Do you need to dynamically generate levels. Can anyone just describe me steps to implement this and what all things needs to be done. Any document or guide would also help. Thanks in advance.
This thread seems to have been dormant a long time, but I thought I'd add a few things I found out about the Advanced Tree Grid widget from working with it.
Quick background: The Parts example PTC provided via the Help Center queries data created inside a Datatable. The data I wanted to display was not persistent, i.e. I needed to generate an output using non-query type services. I think you'd still be able to apply similar methods to what I will describe. Also, I did not create a configuration service; I only statically manipulated the properties of the Tree Grid widget. As part of this configuration, I DID create a Data Shape for the grid which I used for the infotable output to both the "Data" and "ChildData" services I describe below.
1. The "Data" property should be bound to the data (an infotable) that will be loaded up front. You must ensure the service generating this data is triggered in the mashup, such as binding it to mashup Load. I believe this Data is able to include child data that is not expanded below a parent row, the Data infotable must be formatted properly for this. For example, if the table below were the output of your service, the row "item1" should be the only one visible; rows id "item1-1" and "item1-2" should be hidden until you expand the row "item1".
id | parentId | value1 | value2 |
item1 | / | 123 | abc |
item1-1 | item1 | 456 | def |
item1-2 | item1 | 789 | ghi |
2. The "ChildData" property should be bound to the (infotable) output of a service that will be executed whenever you expand a parent row in the Tree grid. This service can be the same as the one populating "Data," but I created a separate one since the logic was going to be totally different. I'm not 100% sure yet whether the DataShape for the "parent" and "child" data services have to be the same.
In order for this "child" service to be useful, it probably needs to know which row you expanded in the Tree Grid. This is accomplished by the "IDFieldName" property of the Tree Grid widget. Per documentation, this property is a unique identifier for the row in the entire Tree Grid. Here's the important part: The value you put in this property should be an INPUT to the service creating the "ChildData." The default value is "id" as it would be in my example table above, but this could also be "value1" or some other heading/field of the table. You just have to make sure the service input name EXACTLY matches this value. Whenever you expand a row (such as item1 above), the "ChildData" service is triggered with the row's value of the "IDFieldName" property included as input.
Example based on my implementation (hopefully not too confusing):
IDFieldName: "contentId"
HasChildrenFieldName: "contentId"
Output for my "Data" service (called at mashup load):
contentId | subcontentId | value1 | value2 |
item1 |
Output for my "ChildData" service (automatically called when I try to expand row "item1" in the mashup):
contentId | subcontentId | value1 | value2 |
item1-1 | 456 | def | |
item1-2 | 789 | ghi |
3. I found that I did not have to use the "ParentIDFieldName" with my implementation that uses a separate service for ChildData. I'm not sure if this fits other use cases.
4. The "HasChildrenField" does not have to have true/false values, but any rows that should be expandable must have a non-false value in them.
Hopefully these insights are helpful!