incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcos Caceres <cord...@marcosc.com>
Subject Re: Naviation Use Cases and whitelist
Date Fri, 03 Feb 2012 20:19:19 GMT



On Friday, 3 February 2012 at 20:06, Filip Maj wrote:

> The neat thing about config.xml is that the elements are
> composable/nestable.  

This is true to a degree…. The W3C spec defines the following algorithm to process XML files:
 
http://dev.w3.org/2006/waf/widgets/#algorithm-to-process-a-configuration-document
   
> 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>

hmm… the WARP parsing algorithm would generally ignore such a construct (see [1]). However,
it could be coerced to work - but it would not be standards compliant.     

[1] http://dev.w3.org/2006/waf/widgets-access/#dfn-rule-for-processing-an-access-element 

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


Also, the src attribute only accepts a Path to local file (I know, that's limiting… but
it was for historical/security reasons). However, in the new version of the spec [2], we could
certainly allow URLs (it was always the intention to allow them at some point, but we just
wanted to get widgets working locally).   
  
[2] http://dev.w3.org/2006/waf/widgets/#the-src-attribute-0


The current way to do the above is without modifying anything is…

 config.xml:  
<widget …>
<access origin="http://mydomain.com" subdomains="true">
</widget>

index.html:  
 <doctype html>
 <iframe style="width:100%; height: 100%" src="http://mydomain.com/mycordovaapp/index.html">

>  
> 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 (mailto: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?
>  


--  
Marcos Caceres




Mime
View raw message