search

amplience / dc-visualization-sdk

For supercharging your Dynamic Content visualizations
https://amplience.github.io/dc-visualization-sdk/
Apache License 2.0
6 stars 1 forks source link

Allow for Visualization SDK to work regardless of context and provided singular API for window messages or content API http calls #21

Open kevin-mitchell opened 3 years ago

kevin-mitchell commented 3 years ago

When using planning / edition / event view to visualize content, the Visualization SDK does now allow us to access the content-item data (Unable to access content form in this view).

This is documented in the readme.md file here, so that was great as it allowed me to verify the exception I was seeing was expected, however it still is inconvenient and feels a bit "incomplete" given visualizing content within editions seems like a perfectly valid and common thing for a person to do.

Describe the solution you'd like

I would like the Visualization SDK to handle all of this for me. In other words, I would like the Visualization SDK to be opaque about WHERE it is getting the data (whether it's from the content API or from window message events, etc). and to just provide the data for visualization purposes that are needed.

I would like to be able to call form.get() or form.update( or something similar, and have these things work exactly the same regardless of the source of content or the context in which we're using the visualization SDK.

The logic that I've written ("do we have contentApi and contentItemId query parameters?" "Are we running in a frame?", etc), should all be handled internally / opaquely by the Visualization SDK.

Describe alternatives you've considered

As of now, in our own solution we've implemented a simple try/catch and will fall back to fetching the content-item data over HTTP from the content API if the Visualization form.get() call fails. This works OK, and we could perhaps improve it by doing something like inspecting the parent window to detect if we are inside of an "edition" view and defaulting in those cases to fetching content from the content API... it would just be a lot nicer if this could be made more transparent to us, and we could use the Visualization SDK as THE source of content-item data.

Thank you for reading!

github-actions[bot] commented 3 years ago

Welcome to Amplience community! Thanks so much for creating your first issue ✔️

pixelscript commented 3 years ago

Thanks a lot for your feedback Kevin, we're taking it under advisement.

Muhammadumer01 commented 1 year ago

Hey @kevin-mitchell , Can you post the solution you have implemented as a work around?

kevin-mitchell commented 1 year ago

@Muhammadumer01 unfortunately I'm no longer with the organization where I wrote this code, so I'm not able to provide much (note to self: next time post a simple code example in my original question for posterity!).

From what I recall though it wasn't particularly complex - as I mentioned I believe I just found that I had to wrap one of the methods for fetching data in a try / catch, and if that failed then I fell back to the other method of fetching data.

It's been a while since I've used the SDK so I'm not actually sure if this approach is still valid (or needed frankly!), perhaps somebody from the Amplience team might be able to be more help.

Good luck!

Muhammadumer01 commented 1 year ago

@kevin-mitchell Thanks man