incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Naviation Use Cases and whitelist
Date Fri, 03 Feb 2012 20:06:12 GMT
The neat thing about config.xml is that the elements are
composable/nestable. WebWorks employs this for some of their stuff too,
for example consider this use case that is doable in WebWorks with the
help of config.xml:

You set your app's <content> element to point to some start page within
your app package, i.e. index.html. But you want to iterate on your app
development faster, so instead of redeploying your app to clients every
time you make a change, instead you change the start page to point to some
page online, I.e. http://mydomain.com/mycordovaapp/index.html. In
webworks, you can nest the various elements inside each other, so you can
do:

<access origin="http://mydomain.com" subdomains="true">
  <content src="http://mydomain.com/mycordovaapp/index.html" />
</access>

This would explicitly allow the start page to be loaded from a remote
location.

We could employ the same thing for plugins. Assuming plugin definitions
would be specified declaratively in the config.xml with the help of
<feature> elements, you could nest <feature> elements inside <access>
elements, for example.

I like this approach from a user of cordova perspective. The
implementation will be a bit more challenging I think :r

On 12-02-03 11:56 AM, "Shazron" <shazron@gmail.com> wrote:

>> I *highly* suggest we employ config.xml as the abstraction for app
>> configuration/metadata such as whitelisting, orientation locking,
>> application naming, author info, etc. etc.
>
>That's what we agreed (consensus?) in the other thread - one
>config.xml to rule them all.
>
>iOS has other issues with the implementation of the whitelist that is
>not covered by the spec, like I already mentioned (whitelist exemption
>for a particular component, like the ChildBrowser - see my proposal
>for a mechanism for fixing this, earlier - and it is iOS specific)
>unless this situation can be covered by the spec, which after looking
>at the widgets access spec I don't think it is?


Mime
View raw message