cancel
Showing results for 
Search instead for 
Did you mean: 

1.4 SDK - Databound Datasources?

mike_howles4
Active Contributor
0 Kudos

I unfortunately think the answer is "no", but just in case...

Is it possible to create an SDK component 'datasource' handler type that is also databound?  It seems that on the surface, the SDK won't flat out tell me it's impossible, however I don't think it does anything either:

If you can't tell based on the name, my idea would be to follow the Decorator pattern to start with a dataset, and then decorate it with a second, third, etc decorator in various ways.

DS_1 (BW/HANA/UNX datasource) -> DS_2 (Decorator Datasource that could potentially add additional calculation columns) -> DS_3 (Another decorator that does something else, etc) -> Chart/Decorator/etc

I think it's an awesome idea but right now nothing happens even if I get the Data Binding dropdown.  I suspect since the 'metadata' data bound property either exclusively must be thought of as a producer or consumer, it would be difficult to figure out the direction of the data otherwise?

Maybe 1.5 or future could introduce this concept if there's not a way today?

Accepted Solutions (1)

Accepted Solutions (1)

MustafaBensan
Active Contributor
0 Kudos

Hi Mike,

This is a great question.  A similar thought had crossed my mind after reading Reiner's post about What's Coming in Design Studio 1.4 SDK, where the following example use case for Custom Data Sources caught my attention:

"Enrich data from a data source with extra rows and columns, including simple calculations"

With the above statement it wasn't entirely clear whether a standard data source (BW/HANA/UNX) could be incorporated into a Custom Data Source for enhancement as stated in the above example but I hope that it is indeed possible.

Perhaps we'll receive some feedback to confirm one way or the other.

Answers (1)

Answers (1)

reiner_hille-doering
Active Contributor
0 Kudos

Hi Mike, hi Mustafa,

when we implemented the data source SDK, we had all those enrichment scenarios in focus. But simply allowing an SDK data source to be data bound would not have really fulfilled the requirements: For enrichment use cases you often need more than one data source.

As we didn't have a quick good solution, in 1.4 you need a work around: You could e.g. have 1 or more data bound invisible components that bring their result set(s) to the SDK data source, e.g. using JavaScript global variables. This is not nice, but should be sufficient to "survive" until we have a better concept.

Thanks,

Reiner.