Agree with everything Jesse said. cordova.plugins could be considered
"safe", but not required. It's just JavaScript!

On 2/6/13 6:27 PM, "Jesse" <[email protected]> wrote:

>> I would prefer cordova.plugins instead of directly on cordova.
>+1
>
>I agree, and like having core plugins live under cordova.plugins.*, but I
>don't think this should be a requirement of other plugins.
>
>For example: com.dropbox.session.startAuthentication(this);
>makes sense to me
>
>In the end, anyone can come along and make their own aliases anyway ...
>it's only js
>
>var dBox = com.dropbox;
>
>PS: if devs are 'discovering' plugins in web inspector, then they already
>have installed them in their app ... ? And this assumes that web-inspector
>is available on the platform in question.
>
>
>On Wed, Feb 6, 2013 at 6:11 PM, Shazron <[email protected]> wrote:
>
>> I agree with Michal that hanging things off the cordova object can get
>> pretty unmanageable after a while, and having it namespaced under
>> cordova.plugins or something similar would be better.
>>
>> InAppBrowser is a weird one since window.open will work in browsers, but
>> not everything it supports is supported in browsers (addEventListener,
>>etc)
>>
>>
>> On Wed, Feb 6, 2013 at 5:48 PM, Michal Mocny <[email protected]>
>>wrote:
>>
>> > I like the proposal, and do think our extensions should be namespaced.
>> >  However, your one example of InAppBrowser is debatable if it is a
>> polyfill
>> > or extension, and has good arguments for either side.  So, perhaps we
>>can
>> > leave that example (or any other specific plugin) aside, and focus on
>>the
>> > overall proposal.
>> >
>> > I would prefer cordova.plugins instead of directly on cordova.
>> >
>> > I also think it would be nice for devs to discover cordova extensions
>>in
>> > web inspector by just typing cordova.plugins. and see whats available.
>> >
>> > -Michal
>> >
>> >
>> > On Wed, Feb 6, 2013 at 11:33 AM, Andrew Grieve <[email protected]>
>> wrote:
>> >
>> > > Some of our APIs are meant to be polyfills, and some of them are
>>not.
>> > >
>> > > It's great to expose the polyfill-type ones using the
>>standards-based
>> > > symbols. E.g. FileEntry, requestFileSystem.
>> > >
>> > > For the custom ones though, I think it's important for devs to
>>realize
>> > that
>> > > the APIs they are using are custom to Cordova, and will never work
>>in
>> > other
>> > > browsers.
>> > >
>> > > Examples:
>> > > Camera: window.Camera
>> > > InAppBrowser: window.open()
>> > > globalization: navigator.globalization
>> > >
>> > > There's been some talk about deprecating the window.plugins
>>namespace.
>> > But
>> > > why? I think it would be clearer if these apis were:
>> > > Camera: plugins.camera
>> > > InAppBrowser: plugins.inappbrowser.open
>> > > globalization: plugins.globalization
>> > >
>> > > This makes it much more clear that the APIs are not browser-based
>>ones,
>> > but
>> > > Cordova-specific.
>> > >
>> > > If the rational to get rid of the plugins is to save on a global
>> symbol,
>> > > how about using cordova as the namespace?
>> > >
>> > > cordova.camera.getPicture()
>> > > cordova.inappbrowser.open()
>> > > corodva.globalization.getLocale()
>> > >
>> > > aka:
>> > > cordova.$PLUGIN_NAME.exports
>> > >
>> > > Thoughts?
>> > >
>> >
>>
>
>
>
>-- 
>@purplecabbage
>risingj.com

Reply via email to