cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: XML Namespaces
Date Mon, 17 Feb 2014 22:27:51 GMT
almost certain we could align down to a single configuration for everything
safely extending package.json (and treating
./platform/whatever/[...]/www/config.xml as compile targets

also almost certain this is not actually important!


On Mon, Feb 17, 2014 at 1:13 PM, Jesse <purplecabbage@gmail.com> wrote:

> If this only refers to the cli project level config, then I withdraw my
> objection.
>
> However, consistency creates clarity.
>
> Maybe taking a step back, why do we have different config.xml files per
> platform anyway? Given that they are all following the same spec ( our
> modified widget spec ) shouldn't they all be capable of reading
> feature/param[@name="X"] and only applying the preferences they support?
>
>
> @purplecabbage
> risingj.com
>
>
> On Mon, Feb 17, 2014 at 12:55 PM, Axel Nennker <ignisvulpis@gmail.com
> >wrote:
>
> > <projectdir>/config.xml vs. <platform>/config.xml
> >
> > <projectdir>/config.json could be used to generate e.g.
> > platforms/android/config.xml
> > or similar on platforms that need/prefer XML
> >
> >
> > Am 17.02.2014 20:33 schrieb "Jesse" <purplecabbage@gmail.com>:
> > >
> > > The config.xml file is currently read at launch on all platforms to
> > decide
> > > what the start-page is, any preferences that exist, and what features
> are
> > > allowed.
> > > This has deeper implications than just cli projects.
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Mon, Feb 17, 2014 at 11:26 AM, Brian LeRoux <b@brian.io> wrote:
> > >
> > > > this is at the project level (cli projects) not the platform level
> so I
> > > > think we're ok
> > > >
> > > > that said, this whole discussion reeks of bikeshed
> > > >
> > > >
> > > > On Mon, Feb 17, 2014 at 11:17 AM, Jesse <purplecabbage@gmail.com>
> > wrote:
> > > >
> > > > > FYI. Windows Phone SDK and Windows 8 'native' .net SDKs do NOT
> > provide a
> > > > > library to parse generic json objects, while reading XML is
> trivial.
> > > > > I could easily add the 6MB JSON.net [1] library to support this,
> but
> > I
> > > > have
> > > > > avoided every dependency I could in getting to this point, so I
> would
> > > > > rather not. I would likely have to write ~400 LOC to use the
> > > > > DataContractJsonSerializer to parse the file, which isn't a huge
> > deal,
> > > > but
> > > > > should be considered. I always strive to write as little code as
> > > > possible.
> > > > >
> > > > > Please keep in mind the 'native' implications of making the move
to
> > .json
> > > > > only, and not just the convenience of inspecting, authoring, and
> > > > modifying
> > > > > the config file.
> > > > >
> > > > >
> > > > >
> > > > > [1] http://james.newtonking.com/json
> > > > > [2]
> > > > >
> > > > >
> > > >
> >
> >
> http://msdn.microsoft.com/en-us/library/system.runtime.serialization.json.datacontractjsonserializer(v=vs.110).aspx
> > > > >
> > > > >
> > > > > @purplecabbage
> > > > > risingj.com
> > > > >
> > > > >
> > > > > On Mon, Feb 17, 2014 at 8:34 AM, Josh Soref <jsoref@blackberry.com
> >
> > > > wrote:
> > > > >
> > > > > > Jonathan wrote:
> > > > > > > It fits more naturally with some 'native' tools (e.g. android
&
> > > > windows
> > > > > > 8).
> > > > > > > IDE's have better support for it.
> > > > > >
> > > > > > This is changing
> > > > > >
> > > > >
> > > >
> >
> >
> http://blogs.msdn.com/b/visualstudioalm/archive/2014/02/06/json-debugger-visualizer-in-visual-studio-2013.aspx
> > > > > >
> > > > > > > If you're developing only with css,js,html -> json makes
more
> > sense
> > > > > >
> > > > > > > If you're developing using native tools (plugman flow)
-> xml
> > makes
> > > > > more
> > > > > > sense
> > > > > >
> > > > > > Tools evolve. I don't see this as a particularly strong argument.
> > > > >
> > > >
> >
>

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