I suggest to introduce e.g. <resource-file src="glass.xml" target="/res/xml/glass.xml/> for Android and other platforms that need it. One platform already has it. Can't remember which. Plugman would then add/remove that file.
Axel Am 31.12.2013 19:57 schrieb "Ross Gerbasi" <[email protected]>: > Thats not a bad idea, would we then inform the user to edit the plugin.xml > after they add it? Remember we need user to be able to customize > PRODUCT_NAME somehow. > > And editing strings.xml isn't horrible it just breaks abstraction of a > plugin. So if you edit it, then remove it it wont remove the entries you > have modified. So when you add it again you have 2 and that throws an > android compile error. > > The other issue is with a team working together. If we do not want people > checking plugins & platforms into source control then other team members > need to add all the plugins themselves and they would then need to modify > the xml file in the same way. Not major but again just these little > branches that pop up. Would be cool if we could tighten it up with some > solution. > > > On Tue, Dec 31, 2013 at 12:34 PM, Andrew Grieve <[email protected] > >wrote: > > > Tough call on this one. I'm a bit wary of letting plugins install hooks, > > because that power could be abused. > > > > Maybe we could allow variables to be used by plugin.xml. E.g.: > > <config-file target="res/values/strings" parent="/*"><string > > name="my_val">{$PRODUCT_NAME}</string></config-file> > > and in config.xml: > > <preference name="PRODUCT_NAME" value="foo" /> > > > > That said, I don't think it's that bad to tell users to edit their > > strings.xml file. > > > > > > On Tue, Dec 31, 2013 at 11:50 AM, Ross Gerbasi <[email protected]> > wrote: > > > > > Hello all, > > > > > > I am trying to work through the best solution to this problem figured > it > > > was smart to bring it up to everyone here. Maybe there is a way to > handle > > > this but I haven't come across it. > > > > > > This problem came up in my Google Glass plugin but I am sure other > > plugins > > > will need to handle this also. > > > > > > In the strings.xml resource we need to set a "voice trigger" element > > which > > > is used to start the app when you talk to glass. There doesn't seem to > be > > > any way to do this with code and this string would be different for > ever > > > app out there. On top of that each voice trigger can optionally have > > > prompts that follow it, to get more user input. Currently I just inform > > the > > > user via documentation to go edit this xml file after they install the > > > plugin. > > > > > > This is not good though because once they do that it is unhooked from > the > > > plugin add/remove workflow. if they remove the plugin those xml > elements > > > stay, and then if they add the plugin back everything starts to become > a > > > mess. > > > > > > Essentially I need a way to write to a xml resources before a user > does a > > > build. I also need to be able to access a config file, probably > > config.xml, > > > in order to get the information to write to this resource. > > > > > > I am thinking maybe we allow plugins to have hooks also? So each plugin > > > could have a hooks folder, which would then allow every plugin to run > > > before build commands. I could then open that resource, grab the > element > > > and write the value in there before every build. > > > > > > Plugins do offer the ability to get variables during add with the > > > --variable flag, but i found this to be a huge mess. Especially when > > > dealing with plugins that have dependent plugins that need variables. > It > > > also is a problem if you install the plugin then add platform after it > > was > > > looking for variables at the wrong time. Anyway this ended up being no > > good > > > for me. > > > > > > I am all for any suggestions, and I can dive into the CLI code and try > to > > > hack together something to get it working but I would love to get some > > > direction. Any ideas? > > > > > > -ross > > > > > >
