-
Notifications
You must be signed in to change notification settings - Fork 7
Splitting concepts responsibility #7
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
Conversation
Separated the concepts and responsibilities of the Code Generators to avoid the confusion caused by partial classes. I applied RawString to format the unit manager code. This makes the code more readable and eliminates the use of AppendLineLF. I reorganized the namespaces to focus efforts on the code generators and avoid the distractions of utility classes. All the business logic is now under Generators. Utilities and satellite classes are under Tools. Extension methods under Extensions. Diagnostics have been grouped under the Rules class. I added a new one to track fatal errors and list it in the output. I also added various extensions to streamline the code. Reworking the code, I noticed that by not using the CodeGeneration option. The different classes don't go through the CurrentUICulture (which is problematic if you're using the tool in a Roslyn project). Now that the class responsibilities are clearly defined, I could add a new Generator to the IStringLocalization model. This interface is used in WinUI and Blazor projects, among others.
Using heritage pattern over the generators to clarify witch every class do. To clarify and simplify concept, separation of concepts. Unification of all Diagnostics in a class Analyzer to respect the Analyzer contract from MS RoslynAnalyser. Rebrand the SourceGenerator class to switch over a new option GenerationType : - ResourceManager (Default) - CodeGeneration (In addidition to GenerateCode, to maintenability of existing code) - StringLocaliser (new generator includes registration classes to simplifing adding resources to the CollectionService) I added a demo project to demonstrate the new feature. I optimized the uses of IncrementalProviders to avoid to apply the same filter over and over. Now we have thee bloc of generation - ResourcesManager - CodeGeneration - ComboGeneration - StringLocaliser - NamespaceRegistrator - GlobalRegistrator
Replace the Tab in .editorconfig readjust files to <tab> instead of spaces readjust unit tests
ycanardeau
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is quite large, so it will take some time to review. It would be helpful if you could split it into multiple smaller parts.
Add comment to enum GenerationType
Correction of typo in documentation
Report the README to XML comment on code to Intellisense purpose
In C#, the * and ^ operators have the same precedence, and evaluation is performed from left to right. So it's not strictly necessary, but I'll add it for clarity.In C#, the * and ^ operators have the same precedence, and evaluation is performed from left to right. So it's not strictly necessary, but I'll add it for clarity.
Also reverted the original comportment on Test2.resx
The global registration class generated even if no StringLocalizer was present Pass the message of exception instead of exception in case of fatal error Environement.NewLine not recommended for Analyser and Generator. I changed for a constant Adjust the Unshipped.md Add a QUICKSTART.md to have a global view of possibilities the option and simplify configuration for new and current users.
|
Hi, @ycanardeau Did you have time to spot last update, I applied your recommendations. Note that I create a nuget on my actual project. I use the ResourceManager and ILocalizer modes. At this time it seem to work perfectly. And I can now generate ResxManager without the problematic "System.Globalization.CultureInfo.CurrentUICulture.LCID" for RoslynAnalyzer. I adding changeset 1cb23f0 after using it in real environment and spot somes irritants. I updated documentation to adding a quick reference to help for configuration. Have a nice day, let me know if you want I adjust something else. |
|
Hi @ycanardeau, It's been a while since I've heard anything. I'm currently running an unofficial Nuget package published on a local server. Eventually, I'll have to switch to an official Nuget package... do you understand my dilemma? Is there still hope of seeing my code integrated, or are you suggesting me to start a new branch and publish another version of the library? |
Continue work from #7: Split responsibilities and prepare for merge
|
Thank you! |
|
Thank you too, don't hesitate if you have some ideas or suggestions I can Help. :-) |
Closes #6.
Separated the concepts and responsibilities of the Code Generators to avoid the confusion caused by partial classes.
I applied RawString to format the unit manager code. This makes the code more readable and eliminates the use of AppendLineLF.
I reorganized the namespaces to focus efforts on the code generators and avoid the distractions of utility classes. All the business logic is now under Generators.
Utilities and satellite classes are under Tools.
Extension methods under Extensions.
Diagnostics have been grouped under the Rules class. I added a new one to track fatal errors and list it in the output.
I also added various extensions to streamline the code.
Reworking the code, I noticed that by not using the CodeGeneration option. The different classes don't go through the CurrentUICulture (which is problematic if you're using the tool in a Roslyn project).
Now that the class responsibilities are clearly defined, I could add a new Generator to the IStringLocalization model. This interface is used in WinUI and Blazor projects, among others.