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) Thx! Sergey -----Original Message----- From: Jonathan Bond-Caron [mailto:jbo...@gdesolutions.com] Sent: Thursday, March 6, 2014 9:31 PM To: dev@cordova.apache.org Subject: RE: Proposal: hooks support for plugins On Thu Mar 6 11:41 AM, Michal Mocny wrote: > On Thu, Mar 6, 2014 at 11:16 AM, Jonathan Bond-Caron < > jbo...@gdesolutions.com> wrote: > > > On Wed Mar 5 04:13 PM, Michal Mocny wrote: > > > For cli workflow: hooks (including plugin hooks) can access > > > config.xml <preference>'s for things like the sqllite compile > > > example (recompile > > only if > > > settings changed would be nice), and access <preference> at > > > runtime for > > the > > > console example. > > > > > > For old workflow, perhaps sqllite is documented to manually run > > > the hook > > to > > > recompile whenever you want to change the default setting? > > > > > > Just thinking about alternatives and/or solutions that are > > > actually > > feasible short > > > term. > > > > > > > Ya it could work, maybe something like: > > <preference name="cordova-plugin-console@install" > > value="--prefer-console true" /> (passed to an install script) > > > > Thats not what I am suggesting. I am suggesting: > > <preference name="cordova-plugin-console-some-setting" value="true" > /> > So... <preference name="cordova-plugin-console/install/some-setting" value="true" /> <preference name="cordova-plugin-console/blah/some-setting" value="true" /> <preference name="android/cordova-plugin-console/blah/some-setting" value="false" /> Looks like a windows registry to me, build a tree from it. Heck, everything is just a preference (sarcasm): <preference name="android/icon/[56x56]" value="some/path.png" /> <preference name="android/app/name" value="broken app" /> Ultimately 'preference' tag always wins. Joke aside, the part that's special about the plugin hooks is a need to track installed files for uninstall() & the security issue (sandbox or not).
