On Wed, Feb 6, 2013 at 9: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. > required, no, but I wonder if we cannot give them a guideline to look up to. Maybe cordova.plugins.* should be reserved for core plugins only, or maybe we advise that extensions/non-polyfils should preferably be added there instead of on window unless they already have a separate namespace (like your dropbox example, or, heck, chrome.* for chrome apps api's ;). > > 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. > You have a good point, I guess this isn't really an important case. I was just dreaming of how cool it would be if the state of plugins was such that quality&consistency was high enough to be able to just install a batch of plugins and discover what they do without reading a tutorial. Examples of batch installs would include "core" plugins, 3rd party project setup scripts (like yeoman or something), or just tinkering with cordova-cli plugin search. > > > 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 >
