cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Date Wed, 23 Apr 2014 17:58:17 GMT
On Wed, Apr 23, 2014 at 1:51 PM, Gorkem Ercan <gorkem.ercan@gmail.com> wrote:
> On Wed, Apr 23, 2014 at 1:26 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
>> Gorkem has an initial implementation posted here:
>> https://github.com/apache/cordova-cli/pull/165 -- but its missing a change
>> previously discussed to support explicit "cordova restore" instead of
>> auto-restore-on-prepare.  He also made us a video:
>> https://www.youtube.com/watch?v=bc60WAQdOjE
>>
>> The syntax for deps in that patch currently uses <feature> tags and looks
>> like this:
>>
>> <feature name=“Console”>
>>   <param name=“id” value=“org.apache.cordova.console” />
>>   <param name=“version” value=“0.2.7” />
>> </feature>
>>
>> Whereas plugin.xml <dependency> tags look like:
>>
>> <dependency id="org.apache.cordova.file" version="1.0.1" />
>>
>> And the current platform config.xml feature tags look like: (note the
>> caveat Andrew mentions that these are intended to solve a different
>> problem)
>>
>> <feature name=“Console”>
>>   <param name="ios-package" value="CDVConsole" />
>> </feature>
>>
>>
> One could merge the params as below, if one day we actually have a single
> config.xml file. Although id and version are planned to be used at the
> build time at the moment I think something like app harness could
> appreciate their existence at the runtime.
>
> <feature name=“Console”>
>   <param name="ios-package" value="CDVConsole" />
>   <param name=“id” value=“org.apache.cordova.console” />
>   <param name=“version” value=“0.2.7” />
> </feature>

Definitely useful to have at runtime. Currently app-harness tacks them
onto cordova_plugins.js in an ugly way!

I don't think they could be merged, because the app developer doesn't
actually know the name="value" part, only the plugin does.

E.g. what you'd actually see in top-level config.xml is:

<feature>
   <param name=“id” value=“org.apache.cordova.console” />
   <param name=“version” value=“0.2.7” />
</feature>

or maybe:
<feature name="org.apache.cordova.console">
   <param name=“version” value=“0.2.7” />
</feature>

or maybe:
<feature name="org.apache.cordova.console@0.2.7" />


But the point is, the name="" attribute that you see in the platform
config.xml is a token that us used in the bridge, and is known only by
the plugin.

>
>
>
>> Food for thought.
>>
>> -Michal
>>
>> On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <purplecabbage@gmail.com
>> >wrote:
>>
>> > Can we see a mock version of what this all would like in either case?
>> > I also withdraw my previous +1 for <feature/> after Michal's
>> clarification.
>> >
>> > Sent from my iPhone
>> >
>> > > On Apr 23, 2014, at 9:03 AM, Michal Mocny <mmocny@google.com> wrote:
>> > >
>> > > Actually I don't think of platforms as dependencies. Your app doesn't
>> > need
>> > > android to run on iOS. It needs plugins. Plugin deps may be specific to
>> > > certain platforms, but platforms are targets.
>> > >
>> > > So I think dependency is not ambiguous with platforms.. Though your app
>> > may
>> > > have more deps than just Cordova plugins.
>> > >> On 23 Apr 2014 10:08, "Andrew Grieve" <agrieve@chromium.org>
wrote:
>> > >>
>> > >> I like the <param name="registry"> idea!
>> > >>
>> > >> The main thing I don't like about <feature>, is that it already
means
>> > >> something different in platform config.xml:
>> > >>    <feature name="LocalStorage">
>> > >>        <param name="ios-package" value="CDVLocalStorage" />
>> > >>    </feature>
>> > >>
>> > >> This means that when JS makes an exec() for "LocalStorage", route it
>> > >> to "CDVLocalStorage". JS-only plugins don't inject <feature>,
and
>> > >> <feature> does not contain plugin IDs. If a plugin has multiple
exec()
>> > >> targets, then it *must* inject multiple <feature> tags.
>> > >>
>> > >>
>> > >> <dependency> is much closer, but the meaning is not as clear
in
>> > >> config.xml (e.g. apps depend on platforms as well).
>> > >>
>> > >> So, how about using <cdv:plugin>? Name is quite clear :).
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Wed, Apr 23, 2014 at 12:35 AM, purplecabbage <
>> > purplecabbage@gmail.com>
>> > >> wrote:
>> > >>> I think consistency with input and output config.xml files makes
more
>> > >> sense than consistency with plugin.xml. So +1 <feature/>
>> > >>>
>> > >>> Sent from my iPhone
>> > >>>
>> > >>>> On Apr 22, 2014, at 8:06 PM, Gorkem Ercan <gorkem.ercan@gmail.com>
>> > >> wrote:
>> > >>>>
>> > >>>>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <
>> agrieve@chromium.org
>> > >
>> > >> wrote:
>> > >>>>>
>> > >>>>> Anis - Gorkem wants <feature> since it works with
his IDE. *Why* do
>> > >>>>> you prefer <feature>?
>> > >>>> Just to be clear I am not trying to push for <feature>
because it
>> > works
>> > >> on
>> > >>>> the JBoss/Eclipse IDE now. I do not mind ripping it apart and
>> > >> implementing
>> > >>>> a new editor if there is a good benefit. However I favor <feature>
>> > >> because
>> > >>>> it allows validation and content assist due to its XSD (I think
we
>> > have
>> > >>>> discussed about this earlier) which is probably the only benefit
of
>> > the
>> > >> xml
>> > >>>> markup on a configuration file these days.
>> > >>>>
>> > >>>> If we use dependency for defining the plugins to be restored
it does
>> > not
>> > >>>> mean that <feature> magically disappears. It is still
used by the
>> > >> platform
>> > >>>> runtimes and therefore the CLI generated config.xml files.
I guess
>> > that
>> > >>>> would mean we still need to keep the documentation etc for
it
>> around.
>> > >>>>
>> > >>>> Also one thing that I have noticed when implementing the restore
for
>> > >>>> plugins because all the information is given as <param>s
under
>> feature
>> > >> it
>> > >>>> is very easily extendible. For instance if someday we want
to
>> support
>> > >>>> enterprise plugin registries, we could just add <param
>> name="registry"
>> > >>>> value="http://registry.acme.corp" /> and use the value on
the
>> > >>>> implementation. Same could be done to dependency by adding
another
>> > >>>> attribute which would break the validations etc.
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>>> On Tue, Apr 22, 2014 at 6:56 PM, Anis KADRI <anis.kadri@gmail.com
>> >
>> > >> wrote:
>> > >>>>>> I prefer <feature>.
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky
<
>> > kamrik@google.com
>> > >>>
>> > >>>>>> wrote:
>> > >>>>>>
>> > >>>>>>> I prefer the <dependency> syntax. It's shorter,
more intuitive
>> and
>> > >>>>>>> consistent with plugin.xml. I don't see much value
in _partial_
>> > >>>>> compliance
>> > >>>>>>> with the w3c spec.
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> On Tue, Apr 22, 2014 at 1:31 PM, Michal Mocny <mmocny@google.com
>> >
>> > >>>>> wrote:
>> > >>>>>>>
>> > >>>>>>>> Gorkem is adding awesome feature to restore
plugins/platforms
>> your
>> > >> app
>> > >>>>>>>> depends on.  There is some debate on the correct
syntax to use
>> in
>> > >> the
>> > >>>>>>>> config.xml file: do we use (a) plugin.xml style
<dependency>
>> tags,
>> > >> or
>> > >>>>> (b)
>> > >>>>>>>> w3c widget spec <feature> tags?
>> > >>>>>>>>
>> > >>>>>>>> Gorkem votes (b), arguing that using widget
spec helps his tools
>> > >> with
>> > >>>>>>>> editing config.xml (existing gui editor, I
assume?), and has
>> > >>>>> implemented
>> > >>>>>>> a
>> > >>>>>>>> PR for it (https://github.com/apache/cordova-cli/pull/165).
>> > >>>>>>>>
>> > >>>>>>>> I vote (a), arguing that we already don't match
widget spec, and
>> > >>>>> already
>> > >>>>>>>> have established syntax for for specifying
plugin urls &
>> versions
>> > in
>> > >>>>>>>> plugin.xml (with docs and examples), and its
better for our CLI
>> > >>>>>>>> implementation to use existing plugin deps
handlers.
>> > >>>>>>>>
>> > >>>>>>>> What do you think?
>> > >>>>>>>>
>> > >>>>>>>> Background: read full thread titled "[GitHub]
cordova-cli pull
>> > >>>>> request:
>> > >>>>>>>> CB-6469"
>> > >>
>> >
>>

Mime
View raw message