Consolidate CSharp and TypeScript Generation and allow for other templates directories and file extensions

[JohnGoldInc]

Is your feature request related to a problem? Please describe. No

Describe the solution you'd like A way to add own Template Directories and different File Extensions then just .ts and .cs (allowing for .razor, .cshtml ...)

[tonysneed]

Hi @JohnGoldInc, thank you for suggesting these enhancements. It looks like you have two requests.

1. Add your own template directories.
2. Add different file extensions other than just .ts and .cs.

For (1): This looks the same as #140 and #73. Is this your intention? If so, would you mind creating a PR just for this requested feature? For (2): What is your motivation for enabling language options for languages besides C# and TypeScript? Do you have a specific language in mind, such as F#? I'm not sure about your reference to .razor, etc. This is, after all, a Handlebars templating solution. 😄

Thanks for providing more background info to help me evaluate your issue.

[JohnGoldInc]

Yes #140 & #73 seem same line of thought.

I want to generate .razor files personally, so c#/html

On Mon, Apr 5, 2021 at 4:55 PM Anthony Sneed @.***> wrote:

Hi @JohnGoldInc https://github.com/JohnGoldInc, thank you for suggesting these enhancements. It looks like you have two requests.

1. Add your own template directories.
2. Add different file extensions other than just .ts and .cs.

For (1): This looks the same as #140 https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/140 and #73 https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/73. Is this your intention? If so, would you mind creating a PR just for this requested feature? For (2): What is your motivation for enabling language options for languages besides C# and TypeScript? Do you have a specific language in mind, such as F#? I'm not sure about your reference to .razor, etc. This is, after all, a Handlebars templating solution. 😄

Thanks for providing more background info to help me evaluate your issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-813644320, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVE3RH74VIAOL75NFOK3THIPSXANCNFSM4Z2CVJMA .

[JohnGoldInc]

@tonysneed re-reading #140 & #73 they seemed to want to change the file names .. mine provides a way to change directory names but not file names. But if fulfils the same purpose I believe as these Issues were pre directories, and they wanted a way to have multiple script files partials to switch between.

[JohnGoldInc]

@tonysneed to clarify this generates other files with different file extensions ( currently limited to .ts and .cs, I want .razor)

[JohnGoldInc]

@tonysneed can't split the PR btw, making it generic between TS and CS generation is also how customized generation becomes possible

[tonysneed]

Hi @JohnGoldInc,

Thanks for helping me understand the purpose of your proposal. I'm not sure if the ability to generate files other than C# or TypeScript (in your case Razor) is a feature that is desired by a significant number of people. I would like to see this issue upvoted by some folks before adding this capability.

What I can do instead is show you how you can generate .razor files using currently available extensibility hooks, in particular, extending Handlebars generator classes, an example of which you can find here.

You can start by creating a HbsRazorModelGenerator class that extends HbsCSharpModelGenerator, in which you can specify a FileExtension to equal ".razor". You can then create a RazorEntityTypeGenerator class that extends HbsCSharpEntityTypeGenerator and override the GenerateXXX methods to create the template data. Then by updating Class.hbs you can customize the generated output. So even without changing the directory and file names, you can still attain your objective of generating razor files using this framework and Handlebars templates.

This is not to say that your other proposed improvements are not valid or beneficial. In fact, I would like to allow users to be able to specify their own partial templates as was proposed by #140 and #73. If you would like to create a PR for this it would be greatly appreciated. Likewise, some of your other LanguageOptions have merit as well, such as AddTripleSlashToComments. But I would like to see these have their own Issues and PR's. The smaller and more focused a PR can be, the better. 😄

I hope this is helpful and look forward to your proposals and contributions!

[JohnGoldInc]

I respect that you have to make these calls on what to allow as PRs; but to iterate my arguments.

HbsRazorModelGenerator will make a Third set of classes and templates that would need to be maintained in the github solution... I feel it would be better served to make TypeScript and CSharp generation generic enough to be done by same classes (and halve the number of updates needed on architecture changes); instead of adding another generator/set of templates and Tripling the number of updates needed in any future architecture changes.

Also I am not really interested in sharing my razor templates as they're, 1) not done, and won't be done soon, 2) would not work with other peoples styles as I am planning on doing something pretty wild 3) I am not interested in making a boring version that others would like 4) I want to keep them mine.

Others can add a LanguageOptions.Razor static option and templates as a PR to the solution easily later if they want to based on this PR

The PR can't be any smaller as it's already a negative change in solution size, removing duplicate code.

On Sun, Apr 11, 2021 at 8:07 PM Anthony Sneed @.***> wrote:

Hi @JohnGoldInc https://github.com/JohnGoldInc,

Thanks for helping me understand the purpose of your proposal. I'm not sure if the ability to generate files other than C# or TypeScript (in your case Razor) is a feature that is desired by a significant number of people. I would like to see this issue upvoted by some folks before adding this capability.

What I can do instead is show you how you can generate .razor files using currently available extensibility hooks, in particular, extending Handlebars generator classes, an example of which you can find here https://github.com/TrackableEntities/ef-core-community-handlebars#7-full-control-extend-handlebars-generators .

You can start by creating a HbsRazorModelGenerator class that extends CSharpModelGenerator, in which you can specify a FileExtension to equal ".razor". You can then create a RazorEntityTypeGenerator class that extends CSharpEntityTypeGenerator and override the GenerateXXX methods to create the template data. Then by updating Class.hbs you can customize the generated output. So even without changing the directory and file names, you can still attain your objective of generating razor files using this framework and Handlebars templates.

This is not to say that your other proposed improvements are not valid or beneficial. In fact, I would like to allow users to be able to specify their own partial templates as was proposed by #140 https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/140 and #73 https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/73. If you would like to create a PR for this it would be greatly appreciated. Likewise, some of your other LanguageOptions have merit as well, such as AddTripleSlashToComments. But I would like to see these have their own Issues and PR's. The smaller and more focused a PR can be, the better. 😄

I hope this is helpful and look forward to your proposals and contributions!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-817397952, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVEZL6YJEY73HM3IJFXTTII2UHANCNFSM4Z2CVJMA .

[tonysneed]

I think you misunderstood my suggestion. It was not to contribute razor generation capability, since I would like this repo to remain focused on generating C# and TypeScript files, but rather for you to achieve your goal in your own private project by extending CSharpModelGenerator and other classes there.

Separately, if you wish to submit one or more PR‘s that are narrowly focused on individual features, I will gladly consider them. For example, you could submit a PR that only has the consolidated C# and TypeScript generation. You can submit another proposed feature, such as an option for enabling triple slash comments, in a separate PR. Each PR should be focused on a single feature, but they can build on one another.

I hope this makes sense. I’m happy to clarify if needed.

Thanks, Tony

On Apr 12, 2021, at 7:06 PM, John Gold Inc @.***> wrote:

I respect that you have to make these calls on what to allor as PRs; but to iterate my arguments.

HbsRazorModelGenerator will make a Third set of classes and templates that would need to be maintained in the github solution... I feel it would be better served to make TypeScript and CSharp generation generic enough to be done by same classes (and halve the number of updates needed on architecture changes); instead of adding another generator/set of templates and Tripling the number of updates needed in any future architecture changes.

Also I am not really interested in sharing my razor templates as they're,

1 not done, and won't be done soon, #2 would not work with other peoples

styles as I am planning on doing something pretty wild #3 I am not interested in making a boring version that others would like #4 I want to keep them mine.

Others can add a LanguageOptions.Razor static option and templates as a PR to the solution easily later if they want to based on this PR

The PR can't be any smaller as it's already a negative change in solution size, removing duplicate code

[JohnGoldInc]

Er, not really seeing a cleaving point to separate things into smaller chunks. I am achieving multiple things at once with the same change.

When merging the generators , comments are handled differently (triple slash for Csharp, vs not for typescript), the feature needs to be there if I don't want to break one of the generators by default .

And making triple slash a configurable thing previous to merging the generators would mean I would have to add the triple slash on/off property to a new parameter or property, making it so previous code that used to work without an extra parameter now needs the extra parameter/property to do triple slashes or not.

i.e. services.AddHandlebarsScaffolding(ReverseEngineerOptions.EntitiesOnly, LanguageOptions.TypeScript , FormatOptions.TripleSlashOff);

or

        services.AddHandlebarsScaffolding(options =>
        {
            options.TripleSlashComments = false;

...

To not break old code it needs to be in the new LanguageOptions object, and LanguageOptions object needs to contain all the aspects that make TypeScript and CSharp Generators different.

On Mon, Apr 12, 2021 at 10:07 PM Anthony Sneed @.***> wrote:

I think you misunderstood my suggestion. It was not to contribute razor generation capability, since I would like this repo to remain focused on generating C# and TypeScript files, but rather for you to achieve your goal in your own private project by extending CSharpModelGenerator and other classes there.

Separately, if you wish to submit one or more PR‘s that are narrowly focused on individual features, I will gladly consider them. For example, you could submit a PR that only has the consolidated C# and TypeScript generation. You can submit another proposed feature, such as an option for enabling triple slash comments, in a separate PR. Each PR should be focused on a single feature, but they can build on one another.

I hope this makes sense. I’m happy to clarify if needed.

Thanks, Tony

On Apr 12, 2021, at 7:06 PM, John Gold Inc @.***> wrote:

I respect that you have to make these calls on what to allor as PRs; but to iterate my arguments.

HbsRazorModelGenerator will make a Third set of classes and templates that would need to be maintained in the github solution... I feel it would be better served to make TypeScript and CSharp generation generic enough to be done by same classes (and halve the number of updates needed on architecture changes); instead of adding another generator/set of templates and Tripling the number of updates needed in any future architecture changes.

Also I am not really interested in sharing my razor templates as they're,

1 not done, and won't be done soon, #2 would not work with other peoples

styles as I am planning on doing something pretty wild #3 I am not interested in making a boring version that others would like #4 I want to keep them mine.

Others can add a LanguageOptions.Razor static option and templates as a PR to the solution easily later if they want to based on this PR

The PR can't be any smaller as it's already a negative change in solution size, removing duplicate code

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-818377638, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVE2KMNQZSGNKMCZAV2TTIORM7ANCNFSM4Z2CVJMA .

[tonysneed]

And making triple slash a configurable thing previous to merging the generators would mean I would have to add the triple slash on/off property to a new parameter or property, making it so previous code that used to work without an extra parameter now needs the extra parameter/property to do triple slashes or not.

Are you saying that, in order not to break existing code after adding the TripleSlashComments option, users of the library would need to add the following code?

services.AddHandlebarsScaffolding(options =>
            {
                options.TripleSlashComments = false;

Why not set the default value of options.TripleSlashComments to false? In that case, it would remain backwards compatible. Am I missing something?

[JohnGoldInc]

That would break CSharp generated code with an uncommented line ... just like setting it to True would make TypeScript weird

On Tue, Apr 13, 2021 at 10:10 AM Anthony Sneed @.***> wrote:

And making triple slash a configurable thing previous to merging the generators would mean I would have to add the triple slash on/off property to a new parameter or property, making it so previous code that used to work without an extra parameter now needs the extra parameter/property to do triple slashes or not.

services.AddHandlebarsScaffolding(options => { options.TripleSlashComments = false;

I'm not getting why you think implementing this feature would break existing code. Why not set the default value of options.TripleSlashComments to false?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-818767590, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVEZIVHQX75E3Q2XBZ2TTIRGGLANCNFSM4Z2CVJMA .

[tonysneed]

Can you give an example of the generated code that would be broken? Maybe seeing it would help me better understand.

[JohnGoldInc]

in CSharp

///

Non Commented Field Comment Text ///

public int SampleField {get;set;}

On Tue, Apr 13, 2021 at 10:17 AM Anthony Sneed @.***> wrote:

Can you give an example of the generated code that would be broken? Maybe seeing it would help me better understand.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-818772863, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVE4VSEIC42TGEETA5UDTIRHAHANCNFSM4Z2CVJMA .

[JohnGoldInc]

In Type Script

/*

• /// Over Commented if set true */ int sampleField ...

On Tue, Apr 13, 2021 at 10:20 AM John Gold @.***> wrote:

in CSharp

///

Non Commented Field Comment Text ///

public int SampleField {get;set;}

On Tue, Apr 13, 2021 at 10:17 AM Anthony Sneed @.***> wrote:

Can you give an example of the generated code that would be broken? Maybe seeing it would help me better understand.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-818772863, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVE4VSEIC42TGEETA5UDTIRHAHANCNFSM4Z2CVJMA .

[tonysneed]

The way this feature now works in the library is that comments only show up in generated code when the table or column is commented in the database. This is not currently configurable. If the comments are in the database, they show up in the generated code (at least the way the templates are currently defined).

Making them configurable, with the default set to false, simply means that the comments don't show up in the generated code.

[JohnGoldInc]

that's not my purpose for the setting .. my purpose is formatting of the comments

if people don't want comments they can edit the template

On Tue, Apr 13, 2021 at 10:25 AM Anthony Sneed @.***> wrote:

The way this feature now works in the library is that comments only show up in generated code when the table or column is commented in the database. This is not currently configurable, if the comments are in the database, they show up in the generated code (at least the way the templates are currently defined).

Making them configurable, with the default set to false, simply means that the comments don't show up in the generated code.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-818778813, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVE2EL2U7B6PQASB4RCLTIRH6BANCNFSM4Z2CVJMA .

[JohnGoldInc]

Care to suggest a better naming? or maybe I should make it a function like the TypeScriptHelper?

On Tue, Apr 13, 2021 at 10:29 AM John Gold @.***> wrote:

that's not my purpose for the setting .. my purpose is formatting of the comments

if people don't want comments they can edit the template

On Tue, Apr 13, 2021 at 10:25 AM Anthony Sneed @.***> wrote:

The way this feature now works in the library is that comments only show up in generated code when the table or column is commented in the database. This is not currently configurable, if the comments are in the database, they show up in the generated code (at least the way the templates are currently defined).

Making them configurable, with the default set to false, simply means that the comments don't show up in the generated code.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-818778813, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVE2EL2U7B6PQASB4RCLTIRH6BANCNFSM4Z2CVJMA .

[tonysneed]

that's not my purpose for the setting .. my purpose is formatting of the comments

Why is this needed? The template data has the content of the comments. The templates contain the formatting.

[JohnGoldInc]

no the /// is done in C# generator, string building it to be in front of every line with the appropriate indent

On Tue, Apr 13, 2021 at 10:48 AM Anthony Sneed @.***> wrote:

that's not my purpose for the setting .. my purpose is formatting of the comments

Why is this needed? The template data has the content of the comments. The templates contain the formatting.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-818796274, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVEYFAQGQXT7F2JONN43TIRKT5ANCNFSM4Z2CVJMA .

[tonysneed]

That's the way it is currently implemented.

    {{#if comment}}
    /// <summary>
{{comment}}
    /// </summary>
    {{/if}}

How are you proposing to to change the implementation?

[JohnGoldInc]

if they don't want comments they will delete the above you quoted from the template, I don't want to change that.

However in C# generator objects, the comment string is massaged to have /// in front of every line (and indented)

In generalizing TypeScript vs CSharp generation into one set of objects I needed to make comment formatting controllable from outside the class so that it put /// for CSharp and didn't for TypeScript, so I made a property that controlled that on LanguageOptions.

Naming changes to the bool property or changing it from a boolean to a passed in function could be possible things I could do to make its proposed purpose more clear.

(if you want a Function I would make a CSharpHelper that would have the Comment formatting function, similar to the TypeScriptHelper )

On Tue, Apr 13, 2021 at 12:01 PM Anthony Sneed @.***> wrote:

That's the way it is currently implemented.

{{#if comment}}
/// <summary>

{{comment}} /// {{/if}}

How are you proposing to to change the implementation?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-818852560, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVE564VM6OUDVK3KLOH3TIRTG5ANCNFSM4Z2CVJMA .

[tonysneed]

If your objective is to consolidate code generation into a single set of classes, then I don't see why you would need to specify whether or not to have TripleSlashComments. This should be a byproduct of the kind of file you want to generate. If C#, then the comments would be formatted with ///; if TypeScript, then not. You would then use some creational design pattern, such as factory or builder, to provide classes that extend a common base class.

However, in light of my decision not to support generating files other than C# and TypeScript, I'm not sure if consolidating C# and TypeScript generation is worth the effort. It does make sense from from the perspective of having a cleaner code base, it wouldn't have much benefit beyond that.

The reason I am against expanding the scope of the library beyond C# and TypeScript is that it is built upon internal EF Core libraries that are geared toward generating C# code. Expanding it to TypeScript was actually a stretch, and my opinion expanding it further would be too much of a stretch.

If you wish to pursue this objective, and you find the Handlebars approach too limiting, I would suggest you have a look at the work Brice Lamb has done with T4 and EF Core Reverse Engineering. T4 is more flexible in some ways than Handlebars, because you can embed code directly in the templates.

[JohnGoldInc]

Having a if = CSharp condition inside the class is just not the right way to do things as it's not very extendable in my opinion.

But I don't want to extend the library itself beyond C# and TypeScript, I just wanted to use a handlebars templating approach on my own stuff outside the library (and I did consider T4). And I thought I'd generate a win-win, smaller code base by abstracting everything that is different between the two and using those abstractions to facilitate external to project customizations.

On Tue, Apr 13, 2021 at 1:14 PM Anthony Sneed @.***> wrote:

If your objective is to consolidate code generation into a single set of classes, then I don't see why you would need to specify whether or not to have TripleSlashComments. This should be a byproduct of the kind of file you want to generate. If C#, then the comments would be formatted with ///; if TypeScript, then not. You would then use some creational design pattern, such as factory or builder, to provide classes that extend a common base class.

However, in light of my decision not to support generating files other than C# and TypeScript, I'm not sure if consolidating C# and TypeScript generation is worth the effort. It does make sense from from the perspective of having a cleaner code base, it wouldn't have much benefit beyond that.

The reason I am against expanding the scope of the library beyond C# and TypeScript is that it is built upon internal EF Core libraries that are geared toward generating C# code. Expanding it to TypeScript was actually a stretch, and my opinion is that expanding it further would be too much of a stretch.

If you wish to pursue this objective, and you find the Handlebars approach too limiting, I would suggest you have a look at the work https://github.com/bricelam/EFCore.TextTemplating Brice Lamb has done with T4 and EF Core Reverse Engineering https://www.bricelam.net/2020/02/03/t4-and-efcore.html. T4 is more flexible in some ways than Handlebars, because you can embed code directly in the templates.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-818903767, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVE5GSVSMMGOJJXKYSNLTIR3V5ANCNFSM4Z2CVJMA .

[JohnGoldInc]

This would also address #165

On Tue, Apr 13, 2021 at 1:56 PM John Gold @.***> wrote:

Having a if = CSharp condition inside the class is just not the right way to do things as it's not very extendable in my opinion.

But I don't want to extend the library itself beyond C# and TypeScript, I just wanted to use a handlebars templating approach on my own stuff outside the library (and I did consider T4). And I thought I'd generate a win-win, smaller code base by abstracting everything that is different between the two and using those abstractions to facilitate external to project customizations.

On Tue, Apr 13, 2021 at 1:14 PM Anthony Sneed @.***> wrote:

If your objective is to consolidate code generation into a single set of classes, then I don't see why you would need to specify whether or not to have TripleSlashComments. This should be a byproduct of the kind of file you want to generate. If C#, then the comments would be formatted with ///; if TypeScript, then not. You would then use some creational design pattern, such as factory or builder, to provide classes that extend a common base class.

However, in light of my decision not to support generating files other than C# and TypeScript, I'm not sure if consolidating C# and TypeScript generation is worth the effort. It does make sense from from the perspective of having a cleaner code base, it wouldn't have much benefit beyond that.

The reason I am against expanding the scope of the library beyond C# and TypeScript is that it is built upon internal EF Core libraries that are geared toward generating C# code. Expanding it to TypeScript was actually a stretch, and my opinion is that expanding it further would be too much of a stretch.

If you wish to pursue this objective, and you find the Handlebars approach too limiting, I would suggest you have a look at the work https://github.com/bricelam/EFCore.TextTemplating Brice Lamb has done with T4 and EF Core Reverse Engineering https://www.bricelam.net/2020/02/03/t4-and-efcore.html. T4 is more flexible in some ways than Handlebars, because you can embed code directly in the templates.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-818903767, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVE5GSVSMMGOJJXKYSNLTIR3V5ANCNFSM4Z2CVJMA .

[tonysneed]

Having a if = CSharp condition inside the class is just not the right way to do things as it's not very extendable in my opinion.

I did not suggest this. Rather, my suggestion is to use a design pattern so that the user would not need to specify how the comments should be formatted. The only option they would need to specify is the kind of generator they want, based on the language option. Then the concrete generator would determine the comment formatting (among other things). Does this make sense?

At first I was thinking about an abstract factory pattern, but since the base generator classes are non-abstract, something like decorator might do the trick.

But I don't want to extend the library itself beyond C# and TypeScript, I just wanted to use a handlebars templating approach on my own stuff outside the library.

Have you considered taking the approach I suggested in this comment? Namely, start by creating a HbsRazorModelGenerator class that extends HbsCSharpModelGenerator, in which you can specify a FileExtension to equal ".razor". You can then create a RazorEntityTypeGenerator class that extends HbsCSharpEntityTypeGenerator and override the GenerateXXX methods to create the template data. Then by updating Class.hbs you can customize the generated output. So even without changing the directory and file names, you can still attain your objective of generating razor files using this framework and Handlebars templates.

[JohnGoldInc]

I am actually wanting to make my own Case tool that generates all my layers from the db (Entity , Api, Client, UI and the UI might need two sets of templates to work right). So I would want to have 5 sets of templates.

If I override HbsCSharpEntityTypeGenerator I can't have a different Template folders

On Tue, Apr 13, 2021 at 7:16 PM Anthony Sneed @.***> wrote:

Having a if = CSharp condition inside the class is just not the right way to do things as it's not very extendable in my opinion.

I did not suggest this. Rather, my suggestion is to use a design pattern so that the user would not need to specify how the comments should be formatted. The only option they would need to specify is the kind of generator they want, based on the language option. Then the concrete generator would determine the comment formatting (among other things). Does this make sense?

At first I was thinking about an abstract factory https://www.dofactory.com/net/abstract-factory-design-pattern pattern, but since the base generator classes are non-abstract, something like decorator https://www.dofactory.com/net/decorator-design-pattern might do the trick.

But I don't want to extend the library itself beyond C# and TypeScript, I just wanted to use a handlebars templating approach on my own stuff outside the library.

Have you considered taking the approach I suggested in this https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-817397952 comment? Namely, start by creating a HbsRazorModelGenerator class that extends HbsCSharpModelGenerator, in which you can specify a FileExtension to equal ".razor". You can then create a RazorEntityTypeGenerator class that extends HbsCSharpEntityTypeGenerator and override the GenerateXXX methods to create the template data. Then by updating Class.hbs you can customize the generated output. So even without changing the directory and file names, you can still attain your objective of generating razor files using this framework and Handlebars templates.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-819111096, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFYVE6YCJQKOBXMQXHFFT3TITGDHANCNFSM4Z2CVJMA .

[tonysneed]

If I override HbsCSharpEntityTypeGenerator I can't have a different Template folders

You can still extend HbsCSharpEntityTypeGenerator to generate razor files. But the way the tool works now, you need to have the template folders in each of your projects, rather than having different sets of folders in one project and targeting your output to different projects.

On Apr 13, 2021, at 7:22 PM, John Gold Inc @.***> wrote:

I am actually wanting to make my own Case tool that generates all my layers from the db (Entity , Api, Client, UI and the UI might need two sets of templates to work right). So I would want to have 5 sets of templates.

If I override HbsCSharpEntityTypeGenerator I can't have a different Template folders

[ghisbo]

In fact this is the exact same reason i have when i asked for generating xaml #165 When one has a good architecture then it is possible to generate all that is needed for a App. in my case for example i want to generate also UserControls, MenuItems,.. that fit in an "Base Admin" application. ideal for development purposes. It makes little sense to retype all the entities en properties in the different application components. So if there is something moving in that direction, i am interested.

[tonysneed]

@JohnGoldInc @ghisbo As the original framework author, I need to be concerned with ongoing maintenance of each feature. As such, I would consider supporting additional languages, such as F#, because there are helper classes available for such scenarios (similar to ICSharpHelper in Microsoft.EntityFrameworkCore.Design). But extending the tool to support general purpose code generation would require development of similar helpers for other file formats.

If you don't want to take advantage of the extensibility model of the framework by extending the base classes, then your other alternative would be to simply fork the repo (as John has already done here). Then you can take it in any direction that suits you. Best wishes for your endeavors!

[ghisbo]

Hello,

I perfectly understand your point and I fully accept it . I do however want to express my thanks for what you have done. Great job and maybe I go for the extensions. For me, it is still unclear how far I want and can go.

Best regards

ghislain borremans

Van: Anthony Sneed @.> Verzonden: woensdag 14 april 2021 15:38 Aan: TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars @.> CC: Ghislain Borremans @.>; Mention @.> Onderwerp: Re: [TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars] Consolidate CSharp and TypeScript Generation and allow for other templates directories and file extensions (#158)

@JohnGoldInchttps://github.com/JohnGoldInc @ghisbohttps://github.com/ghisbo As the original framework author, I need to be concerned with ongoing maintenance of each feature. As such, I would consider supporting additional languages, such as F#, because there are helper classeshttps://github.com/efcore/EFCore.FSharp available for such scenarios (similar to ICSharpHelper in Microsoft.EntityFrameworkCore.Design). But extending the tool to support general purpose code generation would require development of similar helpers for other file formats.

If you don't want to take advantage of the extensibility model of the framework by extending the base classes, then your other alternative would be to simply forkhttps://docs.github.com/en/github/getting-started-with-github/fork-a-repo the repo (as John has already done herehttps://github.com/JohnGoldInc/EntityFrameworkCore.Scaffolding.Handlebars). Then you can take it in any direction that suits you. Best wishes for your endeavors!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars/issues/158#issuecomment-819524776, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP6YZOSSMOPK5ASQJ2O6BX3TIWLEHANCNFSM4Z2CVJMA.

[JohnGoldInc]

Ok Thanks for considering my change