Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ease Transition From XrmToolKit #492

Open
daryllabar opened this issue Apr 18, 2024 · 2 comments
Open

Ease Transition From XrmToolKit #492

daryllabar opened this issue Apr 18, 2024 · 2 comments

Comments

@daryllabar
Copy link
Owner

The XrmToolKit has it's own custom entity generation: https://xrmtoolkit.com/General/GlobalSettings (https://github.com/NHS-Blood-and-Transplant/IRDP/blob/3e380cfc085ff2e7f4768c3e2b5b5573dbffd8a4/NHSBT.IRDP.Plugins/ProxyClasses/Contact.cs)
Some things that would ease the transtion from that to the EBG:

  1. Define a custom Base class, public class SystemUser: BaseProxyType
  2. Be able to change the name of Entity.Fields to be Entity.Properties
  3. Be able to call custom SetPropertyValue with min/max rules rather than OOB.
@janis-veinbergs
Copy link

janis-veinbergs commented Oct 17, 2024

  1. Make EntityNameId Data type non-nullable (Nullable<Guid> -> Guid)
  2. Add static constructor which initializes TextOptions, NumberOptions and ErrorStrings
  3. Add additional methods: SetTextOptions, SetNumberOptions, GetNumberOptions, GetErrorString
  4. Add additional methods for getting optionset textual value for every optionset

@janis-veinbergs
Copy link

janis-veinbergs commented Oct 17, 2024

So I got a new collegue that spent some time on generating earlybounds that could be used to migrate off from XrmToolkit. We didn't generate 1:1 - some refactoring is required for our code that relies on earlybounds. But that is one-time operation.

Our custom service

So we have some code. It is written as a custom service. Some of those things could be useful in upstream project, say custom base class or being able to change name of field.

And actually this code also requires 1 change to be made in upstream project that deals with setting nullable types - additional ignores must be added to InvalidStringsForPropertiesNeedingNullableTypes - I believe this can easily be a configuration option to not break existing code:
image

Settingify?

I was thinking whether ALL the changes could be upstreamed in a way that it takes only configuration to generate this kind of code. A configuration that doesn't involve a single checkbox: make xrmtoolkit compatible code. As xrmtoolkit on itself has different configuration options and we only generated stuff in a way configured for our use case. Moreover it would be more flexible to have different configuration options and a settings template that would work for xrmtoolkit users to provide a migrate path be used.

Here be some struggles with providing configuration options for some tasks:

  1. Going from SetAttributeValue to SetPropertyValue involes passing different parameters depending on datatype... Perhaps it could be configured with multiple configuration items:
  • OverridePropertyGetterName
  • OverridePropertySetterName
  • PropertySetterParameters (Default/XrmToolkit)
  1. It requires static constructor:
		static Account()
		{
			BaseProxyClass.RegisterProxyType(typeof(Account), "account");
			_textOptions = new Dictionary<string, eTextOptions>();
			_numberOptions = new Dictionary<string, eNumberOptions>();
			_errorStrings = new Dictionary<string, string>();
			TextError = "The value for attribute \'{0}\' cannot be longer than {3} characters. The length of" +
				" the value is {2} characters.";
			NumberError = "The value for attribute \'{0}\' must be between {2} and {3}. The value is {1}";
		}

Refactoring

As for refactorings required to code that uses ebg:

  1. Methods to get related items don't exist. I.e: public List<AsyncOperation> GetAccount_AsyncOperations(IOrganizationService service, ColumnSet columns) { return BaseProxyClass.GetRelatedOneToManyEntities<AsyncOperation>(service, this.Id, "asyncoperation", "regardingobjectid", columns); } - use any other way to retrieve them (QueryExpression/FetchExpression/LINQ).
  2. Enums change name, casing - rename. Our code actually had 2 different naming conventions from xrmtoolkit - it started to generate different names, but didn't touch the names that were generated in old way. We don't want to implement logic to preserve this behavior in EBG, rather refactor.
  3. Email.Cc for example is no longer EntityCollection, but IEnumerable - that requires some code refactoring.

Still, without this custom generator class we wouldn't be able to use EBG as we heavily rely on entities being inherited from custom base class and calling SetPropertyValue method which automatically tracks which properties are changed when invoking Update. So after refactoring we can regenerate earlybounds and are good to go.

Upstream?

Soo... I want your thoughts @daryllabar - whether you would like this code to be upstreamed or not. And in such case we can be open whether you don't want to put any effort into taking existing code and weaving into your project or only PR way from our part will work for you.

Additional files.

Attached Account.cs you can diff what we achieved. There are still some work that needs to be done to preserve previous constructors.
Account.zip

I'll send you a link to our source in DM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants