yes! (ideally we kill magic folders and make this explicit in the config)
On Fri, Apr 18, 2014 at 8:35 AM, Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > Sound like most of us prefer module.export. Cool, will update the code > today and let you know once this is done. > > Since we will be moving to cordova-lib the next action item here could be > creating uniform hooks with shared code for both application level and > plugin level hooks. Thoughts? > > Thx! > Sergey > -----Original Message----- > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of > Brian LeRoux > Sent: Friday, April 18, 2014 8:25 AM > To: dev@cordova.apache.org > Subject: Re: Proposal: hooks support for plugins > > like this too / would be much cleaner > > > > On Thu, Apr 17, 2014 at 5:38 PM, Shazron <shaz...@gmail.com> wrote: > > > I like Parashuram's idea. This way the plugin hooks can be testable as > > well? > > > > > > On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN TECH) > > < panar...@microsoft.com> wrote: > > > > > Currently, the plugin hooks are constructed like the hooks in a > > > cordova project. An alternative would be to construct the javascript > > > files to > > have > > > module.exports, and we could pass in the parameters to the function > > > that > > is > > > exported. This way, the module will not spawn a new node process. > > > Comments, Thoughts? > > > > > > -----Original Message----- > > > From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] > > > Sent: Thursday, April 17, 2014 5:19 PM > > > To: dev@cordova.apache.org > > > Subject: RE: Proposal: hooks support for plugins > > > > > > I've sent a pull request with initial implementation for review. > > > https://github.com/apache/cordova-plugman/pull/74 > > > > > > Thx! > > > Sergey > > > -----Original Message----- > > > From: Jonathan Bond-Caron [mailto:jbo...@gdesolutions.com] > > > Sent: Thursday, March 6, 2014 2:07 PM > > > To: dev@cordova.apache.org > > > Subject: RE: Proposal: hooks support for plugins > > > > > > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote: > > > > Can we think about scripts as just a new plugin module? - Similar > > > > to js-module or config-file and which must be processed special > > > > way (by execution). > > > > > > > > <script-module src="src/compile_sqlite.js"/> <framework > > > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/> > > > > <script-module src="src/add_win8_toastCapable.js"/> > > > > <script-module src="src/set_default_target_paltform_arm.js"/> > > > > > > > > Not so powerful and cool, but easy to implement and understand. > > > > During uninstall each script is called again but with 'uninstall' > > > > flag (or each script file can emit install and uninstall > > > > functions) > > > > > > > > > > I'm all for simple, what happens if one of those scripts fails? E.g. > > > failed compile > > > > > > For example in cli: > > > > > > cordova plugin add sqlite > > > platforms = ['android', 'windows8']; for(p in platforms) > > > installPlugin('sqlite'); // android ok! windows8 fails at > > > 'src/compile_sqlite.js' > > > > > > Is 'sqlite' at that point installed on android? Do we rollback the > > > install? Run the uninstall() scripts? > > > > > > For that reason, sandbox idea seems less chaotic with some hookApi - > > which > > > would cleanup properly if something goes wrong... > > > > > > What you're suggesting seems like it could work, until something > > > goes wrong and leaves the platform(s) project/native in an > inconsistent state. > > > Multiple that with "pluginb" that fails at 'src/compile_stuff.js' > > > > > > Could be doable but not sure well it would work. > > > > > > > > >
