cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Suggestion - pluginLoader
Date Fri, 21 Jun 2013 18:27:39 GMT
+1 on the nice proposal.

I have a fork of the BarcodeScanner plugin [1] that uses the plugin spec
and is plugman-compatible. Right at the top of its plugin.xml you can see
it defines the global for the barcodescanner JS as `window.barcodescanner`.

Also, the cordova team is working on breaking out all of the core APIs
into plugins themselves, and all of these core apis/plugins will be
compatible with plugman. Many of them already work with plugman and the
3.0.0 branches of cordova platforms (which have no APIs other than the
exec bridge). Check out the git-wip repos, anything named cordova-plugin-*
[2].

[1] https://github.com/filmaj/BarcodeScanner/blob/master/plugin.xml
[2] https://git-wip-us.apache.org/repos/asf

On 6/21/13 9:21 AM, "J Prince" <princej.ws01@hotmail.co.uk> wrote:

>That looks much more like what I need.
>I think there were two things adding to my confusion;
>
>1. I was not aware plugman could affect the javascript
>2. I don't think I've seen any clean plugman plugins "in the wild"
>
>I will look into the plugin spec a bit further and do some testing with
>it to see what can be done.
>
>
>
>> From: agrieve@chromium.org
>> Date: Fri, 21 Jun 2013 11:28:28 -0400
>> Subject: Re: Suggestion - pluginLoader
>> To: dev@cordova.apache.org
>> 
>> aha, so previously we didn't help plugins along at all.
>> 
>> With plugman-compatible plugins, we do define a way for plugin JS to be
>> loaded: you add a <js-module> tag to your plugin.xml and then plugman
>>will
>> wrap your file in a cordova.define().
>> 
>> Spec: 
>>https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md
>> 
>> You can also specify a <runs/> tag in <js-module> which just causes your
>> .js file to be executed after cordova.js is parsed.
>> 
>> I think with this, you could layer on another module loading system if
>>you
>> wanted something outside of the cordova.define() system.
>> 
>> Does that make sense?
>> 
>> 
>> 
>> 
>> On Fri, Jun 21, 2013 at 10:41 AM, J Prince
>><princej.ws01@hotmail.co.uk>wrote:
>> 
>> > Perhaps my terminology is wrong but ALL plugins define how they are
>>loaded.
>> >
>> > Either (old style) window.plugins = ...
>> > or (new style) cordova.define(...
>> >
>> > My fundamental point is they shouldn't. I don't want my plugins
>>loaded in
>> > either of these ways. The loading of plugins should be separate to the
>> > plugin definition.
>> > Hence my suggestion of;
>> >
>> > cordova.pluginLoader(...)
>> >
>> > In this pattern pluginLoader could either have multiple different
>>modes or
>> > developers could override it (or both).
>> > At the moment I am having to change each plugin to not define its
>>loading
>> > implementation.
>> >
>> >
>> > > From: agrieve@chromium.org
>> > > Date: Fri, 21 Jun 2013 10:22:35 -0400
>> > > Subject: Re: Suggestion - pluginLoader
>> > > To: dev@cordova.apache.org
>> > >
>> > > For your actual app, you're free to use any JS loader that you'd
>>like.
>> > >
>> > > Are there really many existing Cordova plugins that use alternate
>>module
>> > > package definitions?
>> > >
>> > >
>> > > On Fri, Jun 21, 2013 at 9:39 AM, J Prince
>><princej.ws01@hotmail.co.uk
>> > >wrote:
>> > >
>> > > > Hi Andrew,
>> > > >
>> > > > My main point was to make the actual plugin javascript
>>definitions more
>> > > > flexible.
>> > > > That way it would support more unusual developer requirements
>>(such as
>> > > > mine).
>> > > > If the plugin definitions did not contain any loader
>>implementation
>> > then
>> > > > the same definition can be used different ways by different
>>developers.
>> > > >
>> > > > Currently any existing plugins that I want to use I am making my
>>own
>> > copy
>> > > > of and modifying to suit my project.
>> > > > I found this annoying and produced my suggestion based on that
>> > experience.
>> > > >
>> > > > I suppose it is as much for developer simplicity as anything else.
>> > > > A format that supported different use cases would be better for
>>me!
>> > > > It would also mean that the cordova team could more easily change
>>the
>> > > > javascript plugin loader in future without breaking existing
>>plugins.
>> > > >
>> > > > I hadn't thought about dynamically loading the native side of
>>plugins.
>> > > > I was just assuming that would always be loaded.
>> > > >
>> > > >
>> > > > > From: agrieve@chromium.org
>> > > > > Date: Fri, 21 Jun 2013 09:12:42 -0400
>> > > > > Subject: Re: Suggestion - pluginLoader
>> > > > > To: dev@cordova.apache.org
>> > > > >
>> > > > > Hi Jonathan,
>> > > > >
>> > > > > First, thanks for a well-written proposal. At least for me, I'm
>>not
>> > > > really
>> > > > > sure that there is enough of a problem with the current
>>approach that
>> > > > would
>> > > > > justify changing it. That said, business is always an issue,
and
>> > bumping
>> > > > > your thread was the right thing to do :)
>> > > > >
>> > > > > For Android and iOS, the large majority of plugins require
>>native
>> > code in
>> > > > > order to be useful, so I don't think that having plugin JS be
>> > dynamically
>> > > > > seems that useful without being able to dynamically load the
>>native
>> > parts
>> > > > > of it.
>> > > > >
>> > > > > You said that you're serving your app via HTTP. I think your
>>best bet
>> > > > would
>> > > > > be to concat all of your plugin JS together would be by far your
>> > biggest
>> > > > > performance boost rather than try to selectively load them.
>> > > > >
>> > > > > Until very recently, Cordova's module system didn't involve a
>>loader
>> > at
>> > > > > all, and required that all modules be defined ahead of time.
>>Now, we
>> > > > > actually do load plugin .js files during start-up, but still
not
>> > > > on-demand.
>> > > > > So, in my mind we really have two things:
>> > > > > 1. A registry
>> > > > > 2. A boot-up process.
>> > > > >
>> > > > > To be clear - is it that you want to change the registry part,
>>or is
>> > it
>> > > > > just that you want to have plugin .js loaded on-demand? Are you
>> > concerned
>> > > > > about the native side of the plugins?
>> > > > >
>> > > > > One thing I think maybe we should add is the ability to disable
>>the
>> > > > > start-up plugin_loader.js logic for when people want to package
>>the
>> > .js
>> > > > > themselves.
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Fri, Jun 21, 2013 at 8:30 AM, J Prince <
>> > princej.ws01@hotmail.co.uk
>> > > > >wrote:
>> > > > >
>> > > > > > So it's been about a week now and I haven't really had any
>> > feedback on
>> > > > > > this.
>> > > > > > https://github.com/jxp/cordova.pluginLoader
>> > > > > >  I'm not sure if this means;
>> > > > > >
>> > > > > > a) Everyone is too busy
>> > > > > > b) Everyone assumed someone else would respond
>> > > > > > c) No-one is that interested in plugin javascript definitions
>> > > > > > d) You've had similar discussions before and don't want
to
>>start
>> > THAT
>> > > > again
>> > > > > >
>> > > > > >
>> > > > > > > From: princej.ws01@hotmail.co.uk
>> > > > > > > To: dev@cordova.apache.org
>> > > > > > > Subject: RE: Suggestion - pluginLoader
>> > > > > > > Date: Tue, 18 Jun 2013 16:55:19 +0100
>> > > > > > >
>> > > > > > > I have (briefly) looked at Harmony loaders before but
that
>>is a
>> > spec
>> > > > for
>> > > > > > a future javascript language version.
>> > > > > > > I have found a module loader that I wish to use
>>(require.js).
>> > > > > > >
>> > > > > > > My point is that the current suggested module definition
for
>> > cordova
>> > > > > > plugins INCLUDES a loader implementation.
>> > > > > > >
>> > > > > > > I am suggesting that the loader implementation be removed
>>from
>> > the
>> > > > > > plugin to a new method cordova.pluginLoader
>> > > > > > > This would make the plugins cleaner (as they would
only
>>describe
>> > > > their
>> > > > > > own behaviour) and it would also allow cordova or app
>>developers to
>> > > > > > change/customize the loader implementation as needed.
>> > > > > > >
>> > > > > > > My suggested approach would result in plugins that
could be
>> > loaded in
>> > > > > > multiple different ways including (but not limited to);
>>"classic"
>> > > > > > window.plugins, cordova.define and require.js
>> > > > > > >
>> > > > > > >
>> > > > > > > > -----Original Message-----
>> > > > > > > > From: J Prince [mailto:princej.ws01@hotmail.co.uk]
>> > > > > > > > Sent: Monday, June 17, 2013 7:27 AM
>> > > > > > > > To: dev@cordova.apache.org
>> > > > > > > > Subject: RE: Suggestion - pluginLoader
>> > > > > > > >
>> > > > > > > > There are a few main reasons.
>> > > > > > > >
>> > > > > > > > 1. The app I am working on is an Enterprise app.
We are
>> > designing
>> > > > the
>> > > > > > app as a Cordova shell that re-directs to all the html
>>content.
>> > This
>> > > > means
>> > > > > > that we have to dynamically load a different cordova.js
>>(depending
>> > on
>> > > > > > platform) following the redirect.
>> > > > > > > > So we are actually unable to do anything other
than
>>dynamically
>> > > > load
>> > > > > > plugins once the platform specific cordova.js is loaded
>> > > > > > > >
>> > > > > > > > 2. Some of the plugins will be used incredibly
rarely. It
>> > doesn't
>> > > > seem
>> > > > > > necessary to always load plugins until they are needed.
>> > > > > > > >
>> > > > > > > > 3. We are building with a single page architecture
so
>>don't
>> > want to
>> > > > > > end up with lots of script includes in the index.html page.
>> > > > > > > > The define/require pattern feels much cleaner
and better
>> > > > > > compartmentalized.
>> > > > > > > > Our main page currently has 2 script includes:
require.js
>>and
>> > > > jqmobi.
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > >
>> > > >
>> >
>> >
> 		 	   		  


Mime
View raw message