Switch to iFrame

[p-a-s-c-a-l]

In order to support the optimised react build process, we have to switch from React Mount Node to an iFrame.

[DenoBeno]

What does this mean in terms of implementation changes?

On Tue, 23 Jul 2019, 06:21 Pascal Dihé, notifications@github.com wrote:

In order to support the optimised react build process, we have to switch from React Mount Node https://www.drupal.org/project/reactjs_mount to an iFrame.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/clarity-h2020/map-component/issues/37?email_source=notifications&email_token=AAWTC7TO5ER44DVH57MLNYTQA2BLVA5CNFSM4IF7YGNKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HA2GULQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWTC7TXIFUSPJLAZCHIP7DQA2BLVANCNFSM4IF7YGNA .

[p-a-s-c-a-l]

What does this mean in terms of implementation changes?

@therter Does it make any difference?

[therter]

This will at least change the communication betweeen drupal and the app, but there should not be so many changes

[DenoBeno]

See the ticket I posted in "data package". If we already have to change the way communication works, maybe we can do it in a way that will make if usable in data pagkage/resources and not only in the study.

[patrickkaleta]

@therter could this Iframe module for Drupal be of any help for this task?

[p-a-s-c-a-l]

No, this module is too restrictive. We need to pass some properties (study id, etc.) to the iFrame. Either via seamless.js or via a dynamically constructed iFrame URL with several query parameters. So we need a TextField with JavaScript or a custom module.

[DenoBeno]

And if we add the parameters to the page with a view? E.g. some hidden json or xml within the page.

Or a special view that can be called with the page path and returns all the parameters a widget needs?

[p-a-s-c-a-l]

There is already a csis-helpers-module for this functionality available and we use it for the MCDA Application iFrame. So in principle. everything can stay as it is. No need for additional modules, views, etc.

[DenoBeno]

Not sure what the helper module does (https://github.com/clarity-h2020/csis-helpers-module/blob/dev/README.md is not very helpful), but here is a proof of concept for what i had in mind.

• https://csis.myclimateservice.eu/rest/widgets/resource/summary/754

for even more fun, try this:

• https://csis.myclimateservice.eu/rest/widgets/resource/summary/754?reference_type=%40mapview%3Aogc%3Awms

For a given resource, this returns only the references of type map - for the benefit of the map widget

If a widget can query something like this, then it can be made more generic IMO. E.g. a map widget just needs to know "hey, I'm called from page X, let me check if i can find some data to show by requesting a page Y". Where both pages can be related in some simple way, e.g. Y=X/params or such.

[p-a-s-c-a-l]

Map Widget uses the new JSON API, REST Views are based on the outdated REST module. The REST modules's JSON format is different, and we won't support two different JSON formats. But since we need JavaScript anyway, those views don't offer any benefit.

[patrickkaleta]

Not sure what the helper module does (https://github.com/clarity-h2020/csis-helpers-module/blob/dev/README.md is not very helpful), ...

True indeed. I already updated the readme of the csis-helpers module.

[p-a-s-c-a-l]

done