Kinetic Bindings - Seeking Enlightenment

[Chad_Smith]

I just spent an embarrassing amount of time troubleshooting something I thought I had a grasp on, but turns out I do not. As such, I am now seeking some understanding. All examples here are using BAQ as a source.

Short version of the story
Created new dashboard in application studio with a single dataview and single panel grid. Works great. Add second dataview and everything is now broken. Can repeat on demand.

However, if I use the wizard (which is getting better) and create two dataivews and panel grids in the wizard, everything works as intended. After manually adding my criteria, my publish and subscribe functionality even works. Fun note: If you hit the guided setup on the panel grids again at any point after the initial wizard created them, it also seems to break.

I get this super helpful error message.

Now, on the the part where I seek clarification.
There seems to be about 142 different ways (ok this might be hyperbole) you can bind data to a grid in application studio. After dealing with the above issue, it is now clear that I don’t understand what the differences are and when each should be used.

By my count there are actually only 4 places that could be defined. In the properties of the Panel Grid:

• Data: EpBinding (can reference dataview)
• GridModel: EpBinding (can reference dataview)
• Provider Model: EpBinding (can reference dataview)
• Provider Model: BAQ ID (reference native BAQ ID)

The rules seem to maybe not be 100% consistent as it seems to change which ones you should use based on how many dataviews you might have. What works for a single, might not work where there are multiple.

Is there some simple guideline that explains when/why you choose to use some of these over others?

[Olga (Olga Klimova)]

try to open DevTools console window and check red messages there. It must be more descriptive. Undefined just means that error message does not correspond any expecting format and panel cannot show it correctly.

[Chad_Smith]

I deleted the broken versions out of frustration, but I can re-create them and try that to see if the error at least provides better details.

I wasn’t really griping all that much about the error message itself as my lack of understanding how the different flavors of bindings are intended to work.

[Olga (Olga Klimova)]

It may be not even related for your changes.
Personally I often get this message when auth token is expired and client cannot connect to server. Server returns 401 error in that case, but client has troubles to process it correctly and switch back to login page.

[Mike_Tonoyan]

I am wondering myself in which case to use which EpBinding. Did anyone reply?

[dcamlin (David Camlin)]

@Chad_Smith

• Data: EpBinding (can reference dataview)
• GridModel: EpBinding (can reference dataview)
• Provider Model: EpBinding (can reference dataview)
• Provider Model: BAQ ID (reference native BAQ ID)

Here is my unconfirmed assumptions/opinions.

Data EpBinding:
Never played with it when using a panel card grid.

~*~
Grid Model EpBinding:
I always viewed this one for when the grid is going to be populated by data that is already in a DataView. So, if you perform an event/rest-call and pull data from the server into a DataView, you can then link the grid to that data/dataview here. The data, in this case, is locally stored.

Below, I just set up a grid linked to the view “Constant” and it will return all your “constant” values.

~*~

Provider Model EpBinding:
I believe “Provider Model” looks to the server for data vs the Grid Model looking locally for the data. Again, this is an assumption!

The Provider goes to the server for data and then stores it in the dataview you set in this EpBinding property. (so, in that respect, I’m not sure how it truly differs).

I don’t think I’d ever used some of these settings, so I figured I’d play around a bit… You can actually do rest calls right here in the provider model so you don’t need to create an event to populate the resulting dataview!

NOTE: I do NOT have a Customer dataview previously set-up.

But… I can use the Provider Model and it’ll add one for me:

The provider model actually performs the call, returns my GetList:

… creates a “Customer” DataView, and populates it with the returned values:

Those values then populate in the grid:

~*~
Provider Model BAQ ID:
Again, this is going to reach out to the server, but instead of doing a service call, it will use the BAQ service to return data to the dataview you set in the binding (I usually use the binding on the Grid Model).

Here again… I did NOT create a dataview in App Studio ahead of time (BAQView).

I typically always do create it ahead of time, especially because I may be binding other controls/events, etc. to columns within that dataview. But if you’re not doing that, then perhaps creating the dataview ahead of time isn’t necessary at all.

But I defined it in my Grid Model Binding…

I then told the Provider what BAQ to use…

It automatically added and filled the DataView…

And my grid populated with the data.

I did this one again, but set the Provider Model EpBinding instead… and it worked that way as well.

In fact… I never deleted the EpBinding in the Grod Model… I just added the BAQViewPM to the provider model binding and it used that one instead.

… So, to summarize…

They all seem to work (although I didn’t do any testing with the Data EpBinding)… so this exercise ultimately wasn’t very informative or instructive.