I'm working on a Sproutcore UI for a project called "BWUnit". When using sc-gen to create models, etc it converts "BWUnit" to "BwUnit" in the generated files. Is there a way to prevent this from happening so I don't have to manually edit the files, replacing "BwUnit" with "BWUnit"?
so SproutCore unfortunately doesn't support what you want out of the box. This is their naming convention: http://wiki.sproutcore.com/w/page/27759680/FiedNotes-Suggestions%20on%20running%20the%20Sproutcore%20framework%20on%20a%20Windows%20(7)%20computer%20using%20a%20specific
If you are brave, however, you can edit the built tools and change the behavior of how the project and app names are prepared:
https://github.com/sproutcore/abbot/blob/master/lib/sproutcore/models/generator.rb#L462
If this is a feature you want and need, please open an issue here:
https://github.com/sproutcore/sproutcore/issues
Cheers,
Johannes
Related
I want to create a app specific setting(app preference) in iOS(iPad) and read that in my Ionic(v5) code. I have seen plugins like https://github.com/chrisekelley/AppPreferences/ this but not working with the cordova-9 as it was not updated. Looks like this project is abandoned.I was able to create a setting bundle during the build and place it under the settings->Myapp (key-value) but from the program reading is not working.
My requirement is very simple. I need to externalize the back-end server IP/name as it might change sometimes. I was thinking if I can create a property under Settings->MyApp->Server then I can edit it in the Settings and read it while starting the app.
Is there a different approach that I can follow?
Please let me know if you have any pointers.
I am working on a NopCommerce website and have quite a bit of site-wide customization so I have created a plugin to handle it all but not sure on how to handle the localization. I see there are a couple of ways of updating the Localization strings, one way I have found is in the Plugin's Install() method:
this.AddOrUpdatePluginLocaleResource("Plugins.Payments.PayPalStandard.Fields.AdditionalFee", "Additional fee");
This looks like it only adds new resource strings for the plugin, is there a similar way to update the other resources via the Install() method like:
Admin.Catalog.Products.List.DownloadPDF
I found that there is a way to export the entire language to a language_pack.xml file, would it be better to just create an entire language pack instead? Is there a way to add a new language pack from the plugins Install() method?
I guess I could simply open the language_pack.xml file and add each resource found using the AddOrUpdatePluginLocaleResource, I was hoping that there was a built-in way of doing this using NopCommernce functionality.
Thanks!
As #Raphael suggested in a comment, provide a language pack along with plugin file to the end users, and give an option to upload required resource file within your plugin configuration page.
As per as I know, there is no inbuilt way to add language pack on plugin installation, but you can do some code on plugin install method to find language pack file(s) from plugin folder and install it, not quite sure, you can take reference of inbuilt methods.
I am trying to change the number of custom fields I can create in OrgangeHRM PIM section.
I have found a few articles on this site that say what part of the code to change but non saying where to find the file where the code is stored is in.
If anyone can help then that would be great.
I am running version 4.0 of OrangeHRM.
Thanks
orangeHRM have slots for custom field (i dont remember, but i think 10 slot in orange 4.0), you can use this for put what you need.
Out the box, you can follow guides for add more custom or pre-format fields, but not is more recomendable, this can make broken code.
meanwhile, you think work out the box, remember orangeHRM is a symfony based software, if you know how work symfony (MVC framework), work it whit OrangeHRM is more easy
good luck
I was hopping to have an easy way to customize the display behavior of the Grails fields plugin after reading its docs, but I just realized that it demands an enormous effort as there is no available templates to start from.
I can see the display functionality is hard-coded in FormFieldsTagLib (from methods like renderDefaultInput() ) but I think it is imperative to have the templates themselves (or a way to generate them, somewhat like generating static scaffolding in Grails).
I can see no consistent (and reasonable) way to customize display behaviors for the Grails fields plugin without that. Am I missing something?
Imagine the use case where someone wants to change the boolean default rendering just to display the field label after (and not before) the checkbox, and keep it available to all the boolean fields within its application. Which concerns will he need to handle regarding if the field is required, has errors, prefix and so on? When all he needed was just moving two divs around.
Grails version: 2.5.4, fields-plugin version: 1.5.1
You aren't missing something. You'd have to re-create the existing implementation of each field type rendering in a template for use with the plugin. There isn't a way to generate a file to start with (like scaffolding).
I won't bore you with the historical reason as to why this is the case, but if you do create a set of base templates it would be a good idea to contribute back to the plugin.
I had an issue with the <f:table> tag, and found this post, which led me to find the base or default template inside the plugin repo.
Take a look at
https://github.com/grails3-plugins/fields/tree/master/grails-app/views
That may help you finding some default templates, along with the official doc and this answer on where to put the override.
Hope it helps you.
I'm having some trouble merging the localization satellite assemblies into the plugin DLL for CRM2011.
Either that, or I don't know how to use the merged resources afterwards.
I create a few plugins and create a basic resource file (default - English) and one for a specific culture (at the time of writing it's for Polish localizations, but later I'll need to add French as well).
I make sure not to sign the assembly itself, as ILMerge will sign the finished assembly itself.
This is the command I use to merge the extra satellite assembly:
ilmerge /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /log:log.txt /keyfile:KeyFile.snk /out:Plugins.dll DynamicsCRM2011.Plugins.dll pl-PL\DynamicsCRM2011.Plugins.resources.dll
As you can see, the plugins are in .NET 4.0 and I've got the required .config file for ILMerge to use the required assemblies for merging.
The generated file appears fine, I can register it with CRM plugin-registrator, add new steps and so forth.
However, it will always use the default language. I've tried changing the System.Threading.Thread.CurrentThread.UICulture, but this didn't help. When I created a ResourceManager class and used GetString("ErrorMessage", new System.Globalization.CultureInfo("pl-PL")), I got an Exception that the specified ResourceManager doesn't know what to do with the specified culture.
I know of this question here. However, the posted solution seems to be an old one. The generated resource .cs files do not use a ComponentResourceManager. Also, parts of the code posted there have been marked as deprecated.
I'm not really sure what I'm am to do now, or how to further debug this, as I have very little experience when it comes to working with assemblies themselves. Please, help me get those satellite assemblies under control.
Update:
I've been working with sandbox plugins for a while now, and thus I no longer have access to things such as CurrentCulture (or at least I cannot change such things). I've tried tackling this problem once more: I've created a simple plugin which is fired when a new Account is saved. Nothing fancy. Here's the actual plugin code:
ResourceManager rm = new ResourceManager(typeof(Properties.Resources));
var s = rm.GetString("ErrorAlreadyPosted", new System.Globalization.CultureInfo("pl-PL"));
throw new InvalidPluginExecutionException(s);
The code no longer throws an exception about not being able to find the specified culture... also the code obviously throws an exception at the end, but the important thing is WHAT the exception message is. I'd expect it to be in Polish.
Alas, it is not. The string returned by GetString is still in English.
The command I used for ILmerge is the same as before, but with the /lib parameter specified so that I don't have to copy all the CRM SDK dlls...
Apparently it is not possible to read resources from with the context of a Plugin.
Read up on MSDN: http://msdn.microsoft.com/en-us/library/hh670609.aspx#BKMK_UseXMLWebResourcesAsLanguageResources
Quote: When a plug-in requires localized text, you can use an XML web resource to store the localized strings so the plug-in can access them when needed. The structure of the XML is your option, but you may want to follow the structure used by ASP.NET Resource (.resx) files to create separate XML web resources for each language. For example, the following is an XML web resource named localizedString.en_US that follows the pattern used by .resx files.
This is all I know so far - have yet to build my own solution for localization of a crm plugin.
If you use a reflector tool to look at the generated assembly, do you see your resource(s) embedded correctly? You may be experiencing the bug as outlined in the link you posted.
Try setting Thread.CurrentThread.CurrentUICulture and\or Thread.CurrentThread.CurrentCulture.
Also try hooking into the AppDomain.CurrentDomain.AssemblyLoad and\or AppDomain.CurrentDomain.AssemblyResolve to debug which assemblies are being attempted to load and from where. You might need to customize their behavior so that instead of loading an external assembly to load an internal resource instead.
You can try embedding project references as resources instead of using ilmerge as well.
See this: http://bartlomiej.net/dotnet/embeded-assembies-into-an-executable/
The way we eventually handled this is by adding the localization XML files (generated by Visual Studio) as CRM resources, and created a bit of custom code which seeks the appropriate resource and then seeks the localization text inside.
It's, obviously, not as simple as just using the generated C# localization class, and requires some prep work. However, with that prep-work in place and with using nameof it's now almost as simple as the aforementioned resource classes.