Opera extensions (widgets): dynamic config file

Question

I have an Opera 11 extension, which has a background process and an injected script. These communicate very frequently with a remote server (not the webpage the user's viewing), using the background script's cross-site XMLHttpRequest capabilities.

I would like the URL of the server to be a preference, so that it can be modified by the user without editing the package. The config.xml file would good, for it accepts <preference name="serverUri" value="..." />. However, I would like the script to be able to update itself directly from the server (not through Opera's site), which can be achieved using <update-description href="http://myserver.com/client/update" />.

So what I would like to do is have the href attribute of the update-description element to be dependent on the value of the preference serverUri. I would imagine some syntax like this:

<update-description href="{$serverUri}" />

But I could not find any references to this kind of functionality. Is there some way to solve this?

Answer 1

It's not possible to use variables in the config.xml file as you've written and I don't think there are plans to add this.

I'm sure you know that preferences can be set not just with the preference element in config.xml but also using widget.setPreferenceForKey(value, key), but I don't think that solves your problem in this case.

The only workaround I can think of is if you have all your logic in an external script on your server and in your extension's local files (background script or injected script), just have a very simple couple of lines that reference your external script. Something like:

var script = document.createElement('script');
script.src = 'http://www.example.com/script.js';
document.body.appendChild(script);

You could then make the script's URL editable by the user and store it in widget.preferences.

EDIT by hallvors: This solution has serious drawbacks, see my comment below.

Answer 2

As far as I know this is not currently possible. It seems like a bit of an unusual use case, which could potentially be risky to implement, so it would be interesting to hear more about why you want to do this.