cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gorkem Ercan <gorkem.er...@gmail.com>
Subject Re: Unifying the config.xml
Date Thu, 04 Apr 2013 20:48:53 GMT
On Thu, Apr 4, 2013 at 9:17 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Some feedback:
>
> +    <access origin=".*"/>
> +    <access origin="http://127.0.0.1*"/> <!-- allow local pages -->`
>
> Why have the second line? it's made redundant by the first, and when we do
> serve files locally, we do so via file: URLs.
>
>
I have copied this use from the android's existing config.xml [1]. It does
not make much sense to me either but since I did not have time to
investigate it deeply and did not want to break anything, I kept it as it
is. We can easily remove it if you think it will not harm anything for
Android.

[1]
https://github.com/apache/cordova-android/blob/master/framework/res/xml/config.xml



>
>
> +    <log level="DEBUG"/>
>
> I don't see <log> in the widget spec. Seems like a good idea to be able to
> se a log level, but probably would be more appropriate as a <preference>,
> and out of the scope of this change.
>
>
>
Correct, this is not on the spec but Android at the moment is actually
using log element to configure its logging level and therefore it is
present on the current android config.xml. I also agree that logging is not
in the scope of this change and it is  probably a fair amount of work. If
you think the effect on Android is trivial, I can remove it from the
templates.


>
> Using <param> for the class name does more align with the spec, but using
> $platform-package to address platform differences seems out of place
> compared with how these are addressed by CLI's config.xml (using
> gap:platform attributes or <platform> tags). What would be better (I think)
> would be to have <param name="package" value="foo"/>, and use CLI/plugman
> to deal with putting in the correct versions per platform.
>
> E.g., if iOS adds something to its template config.xml file, I don't want
> to have to add this value to each platform's config.xml file.
>
>
>
I wanted to keep it within the spec because any extensions to the widget
spec needs a wider concencus . I used the $platform-package convention but
could be any of the other options as long as it allows us to mark the
element with a platform. I think this is something that needs to be agreed
and continued.



>
>
>
>
> On Thu, Apr 4, 2013 at 1:11 PM, Shazron <shazron@gmail.com> wrote:
>
> > Yes please. I want to get this pain all over with :)
> >
> >
> > On Thu, Apr 4, 2013 at 9:56 AM, Filip Maj <fil@adobe.com> wrote:
> >
> > > Sounds good!
> > >
> > > Ping Shaz, Andrew, Michal, Joe, Simon, and anyone else involved in
> > Android
> > > & iOS.
> > >
> > > On 4/4/13 5:08 AM, "Gorkem Ercan" <gorkem.ercan@gmail.com> wrote:
> > >
> > > >Hi Filip,
> > > >Thanks for looking at this. I have just updated the PR(s) with
> corrected
> > > >config.xml ids for templates on all projects.
> > > >
> > > >I am also planning to send a PR for updates to doc once these are
> > > >integrated.
> > > >--
> > > >Gorkem
> > > >
> > > >
> > > >
> > > >On Wed, Apr 3, 2013 at 6:29 PM, Filip Maj <fil@adobe.com> wrote:
> > > >
> > > >> Hey Gorkem,
> > > >>
> > > >> Thanks for this and putting the effort into kick starting this.
> Sorry
> > > >> about the late reply.
> > > >>
> > > >> I like the changes (made a minor comment re: widget element id in
> the
> > > >> github pull request). Correctly adopting the spec should help.
> > > >>Leveraging
> > > >> several <param> elements inside a <feature> element, one
param per
> > > >> platform, to describe the resolution of native plugin source from
> > > >> cordova.exec service label [1] is elegant.
> > > >>
> > > >> I'm up for +1'ing these changes. Should help with our ongoing plugin
> > > >> tooling work too!
> > > >>
> > > >> Unless other people have problems with this approach, I'll aim to
> > merge
> > > >> this stuff in on Friday. Perhaps some of the core maintainers for
> > > >>Android
> > > >> and iOS can review those particular changes (I trust your judgement
> > more
> > > >> than my high-level understanding :P). If that all checks out, we can
> > set
> > > >> up issues for the Windows Phone platforms, BlackBerry, and other
> > > >>platforms.
> > > >>
> > > >> [1] https://github.com/apache/cordova-android/pull/41/files#L2R57
> > > >>
> > > >> On 4/1/13 2:24 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
> > > >>
> > > >> >I would like this to be reviewed/merged as well because config.xml
> > > >> >differences are becoming a pain in terms of plugin management.
> > > >> >
> > > >> >Android has a /cordova/plugins. iOS had a /cordova/plugins in
2.4
> and
> > > >>now
> > > >> >has a /widget/plugins.  BlackBerry 10 has a /widget/plugins and
is
> > > >> >following the spec by using "feature" instead of "plugin".
> > > >> >
> > > >> >Whatever we decide I would like to have some kind of uniformity
> > across
> > > >> >platforms.
> > > >> >
> > > >> >-a
> > > >> >
> > > >> >
> > > >> >On Thu, Mar 28, 2013 at 12:05 PM, Gorkem Ercan
> > > >> ><gorkem.ercan@gmail.com>wrote:
> > > >> >
> > > >> >> Hi All,
> > > >> >> I am working on a set of plugins for Eclipse that will eventually
> > be
> > > >> >>part
> > > >> >> of the JBoss IDE. I seem to have similar requirements to
> > cordova-cli
> > > >>and
> > > >> >> noticed that some of the things that are planned for cli
is well
> > > >>aligned
> > > >> >> with our plans. So I am hoping to contribute as much as I
can.
> > > >> >>
> > > >> >> We also use W3 widget packaging spec based config.xml as
a
> blanket
> > to
> > > >> >> configure a Cordova App for all platforms. However there
are
> > > >> >>differences on
> > > >> >> the config.xml that each platform consumes compared to the
W3
> spec
> > > >>and
> > > >> >>as
> > > >> >> you can imagine a more uniform platform behaviour makes our
life
> a
> > > >>bit
> > > >> >> better. So I have tried to take a shot at unifying the
> differences
> > > >> >>between
> > > >> >> platforms and created pull requests for android[1]. iOS[2]
and
> > > >>CLI[3]. I
> > > >> >> think with these PRs JIRA[4] for migrating from <plugin>
to
> > <feature>
> > > >> >> should be resolved (at least for iOS and Android) and its
> parent[5]
> > > >> >>should
> > > >> >> be updated.
> > > >> >>
> > > >> >> The changes are compatible with the existing config.xmls
on iOS
> and
> > > >> >> Android, I think it will be even possible to mix and match
the
> new
> > > >> >>syntax
> > > >> >> <feature> with the old ones.
> > > >> >>
> > > >> >> [1] https://github.com/apache/cordova-android/pull/41
> > > >> >> [2] https://github.com/apache/cordova-ios/pull/45
> > > >> >> [3] https://github.com/apache/cordova-cli/pull/7
> > > >> >> [4] https://issues.apache.org/jira/browse/CB-1109
> > > >> >> [5] https://issues.apache.org/jira/browse/CB-1108
> > > >> >>
> > > >> >> --
> > > >> >> Gorkem
> > > >> >>
> > > >>
> > > >>
> > > >
> > > >
> > > >--
> > > >--
> > > >Gorkem
> > > >http://www.gorkem-ercan.com
> > >
> > >
> >
>



-- 
--
Gorkem
http://www.gorkem-ercan.com

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