cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: XML Namespaces
Date Mon, 17 Feb 2014 21:13:16 GMT
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