Skip to Content

1.4 SDK - Databound Datasources?

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?

Add a comment
10|10000 characters needed characters exceeded

Related questions

2 Answers

  • Best Answer
    Posted on Dec 08, 2014 at 02:36 AM

    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.

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Dec 08, 2014 at 08:12 AM

    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.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.