cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: [android] How to remove the automatic default of <access origin="*"/>
Date Thu, 05 Dec 2013 21:04:49 GMT
Nice! I will check it out later today.

On Thursday, December 5, 2013, Michal Mocny wrote:

> Alright, I've landed a defaults.xml for ios and android and closed the long
> standing bugs for this.
>
> Aside from removing the <access> tag, I also removed the settings which are
> overwritten by the app-level config anyway, such as app name, description,
> <content> tag, etc.  Please take a look if you have any concerns.  I did
> leave the default platform preferences/features in there, because those can
> be overridden in the app config and many really are platform specific.
>
> Tested using both the CLI and bin/create workflows to make sure both still
> work and do what we intent.
>
> Now, when a CLI user makes changes to the app config to remove <content> or
> <access> tags, the final platform config actually reflects those changes.
>  Win.
>
> -Michal
>
>
> On Wed, Dec 4, 2013 at 2:31 PM, Tommy-Carlos Williams <tommy@devgeeks.org<javascript:;>
> >wrote:
>
> > +1
> >
> > This is all sounding great and no matter how much I love the CLI,
> > supporting both workflows is important.
> >
> >
> >
> >
> > On 5 Dec 2013, at 6:13 am, Michal Mocny <mmocny@chromium.org> wrote:
> >
> > > Yes, there is no need to change the tools, which is why I like this
> > > approach.  I forgot to mention that part :P
> > >
> > > I did not think we previously discussed supplying both config files
> with
> > > different default settings.  I had previously imagined we would ship
> > > platforms with only one defaults file (defaults.xml/config.xml
> whichever
> > > name) that was consumed by both flows.  The function of a defaults.xml
> > was
> > > as an implementation detail of CLI to help us treat config.xml as a
> build
> > > artifact.  Now I am proposing using it as a first class config file
> that
> > > gets maintained along with config.xml in platform releases.
> > >
> > > -Michal
> > >
> > >
> > > On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson <braden@google.com
> > >wrote:
> > >
> > >> It's possible I'm misunderstanding something here, but the flow you
> > >> described here is exactly the one we intended when designing how
> > >> details.xml was going to work. Platforms ship both files, cli uses
> > >> defaults.xml where available, and config.xml where not. Platform
> scripts
> > >> use config.xml always.
> > >>
> > >> I don't think any (many?) Changes to the tools will be necessary to
> > support
> > >> this.
> > >>
> > >> Braden
> > >> On Dec 4, 2013 8:25 AM, "Michal Mocny" <mmocny@chromium.org> wrote:
> > >>
> > >>> Alright,  Andrew and I discussed this and think we have a resolution
> > that
> > >>> works with all the use cases (yay for options).
> > >>>
> > >>> TLDR; I think we already (accidentally?) support using a different
> > >> default
> > >>> platform config file for each of our two workflows.  This means we
> can
> > >> have
> > >>> the <access origin="*"> tag live inside the platform config for
> > >>> platform-centric workflow, and inside the app config for app-centric
> > >>> workflow.  This means users less surprise for end users, and
> downstream
> > >>> distributions can more sensibly override these types of defaults
> should
> > >>> they chose to.
> > >>>
> > >>> ----
> > >>>
> > >>> Most platforms don't ship with a defaults.xml file yet (except for
> BB;
> > >>> because Jeff did this work, he followed through for that platform).
> > >> There
> > >>> are open bugs to add these (ie, CB-5047).
> > >>>
> > >>> Jeff also added a nice fallback to the CLI: if there does not exist
a
> > >>> defaults.xml when running "prepare", backup the initial config.xml
> to a
> > >>> defaults.xml file before we go messing everything up with plugin /
> app
> > >>> settings.  Effectively the config.xml that ships with platforms is
> the
> > >>> defaults.xml for platforms that don't have one explicitly added.
>  This
> > >> is a
> > >>> great default.
> > >>>
> > >>> However, if there actually were a defaults.xml, the CLI would consume
> > >> that
> > >>> for its initial input in the prepare process, and completely ignore
> the
> > >>> platform config.xml.  The bin/create script would completely ignore
> the
> > >>> defaults.xml file and use only the config.xml file.
> > >>>
> > >>> So, if we shipped both a config.xml *and* defaults.xml, we could
> choose
> > >>> which settings to set for each workflow.  I don't actually think the
> > >>> settings should generally differ, and its mildly annoying that we
> would
> > >>> have mostly duplicated files, but it means we can move such
> "optional"
> > >>> settings as <access> or <dependency> etc out of the platform
config,
> > and
> > >>> into the default app config which lives in cordova-cli, since that
is

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message