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).
