Injecting configuration registry information as JS into Plone 5?

I have some persistent configuration in the configuration registry that must be passed into some JS codes specific to my add-on.

In detail:

This JS codes requires some hyphenation related configuration stored within Plone. Right now it is fetched using AJAX with the help of a browser view...working but not very nice and there a better more canonical way in Plone 5?



Considering how you have implemented your JS, I think your AJAX call to a browser view is probably the best approach.

If you had implemented a Mockup pattern, you would have a better option: you would pass the settings value as attributes in the markup, like this:
<div class="pat-hyphenator" data-pat-hyphenator="selectors:p.myText;minwordlength:15">Here is my text</div>

That way, it is easy to collect every data you need in Python, and pass them to the pattern in ZPT:
<div class="pat-hyphenator" tal:attributes="data-pat-hyphenator view/hyphenConfig" tal:content="context/text" />

The whole idea with Mockup(/PatternLibs) is to create completely autonomous components which can be developped, compiled and tested outside of Plone, and all the settings and data inputs are provided in the markup.

1 Like

Not sure about AJAX being the best approach. I could move the variables into some viewlet code (either holding the data as JS variables or as data attributes on some hidden element). This would eliminate at least a bit of network latency. I don't the purpose Mockup here since I am not working on UI components.


Forget about JS variables, data attributes are way much better.
There are many reasons for that, let's mention 2 of them:

  • script tags in the wild might be easily forget when writing Diazo rules,
  • script tags are not considered when loading a page in AJAX (for instance in a modal).

Note: I think hyphenation is 100% UI related, and it would be a very useful pattern to add to Mockup (if we could just add a class pat-hyphenator on any paragraph to have it hyphenated properly, it would be great).

1 Like

In such case, a hidden form input often works well as a place to hold JSON (and you could traverse to your existing view from your template, instead of by AJAX). I suppose these days, with html5, you can just use any element you want want with a data- attribute as alternative to using a hidden form input.