-
|
It will be nice if developers would have control over code generation process which is responsible for creating External Modules, and which is now hidden inside Module Creator. It will be useful if developer will be able to customize default exposed templates and change default structure of components and services generated within External Module. For example, in case that you are fetching data from external API. Then structure of the services is a bit different. You don't need server side. Also, implementation of the service is a different. There is no need of ServiceBase class, and default behavior will be replaced. In a microservices architecture, where you may want to generate hundreds or thousands of modules, it can save a lot of time if customization is done only once. I don't know which code generation tool is used behind the scene. I think it is not Roslyn because I don't see Microsoft.CodeAnalysis namespace. Is it completely custom solution? It will be great if this would be some template based tool. In that case this feature should be easy to implement. Tell me, what do you think!? P.S. For everything I suggest, I am ready to contribute. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
I think it would be nice to expose code generation APIs as service, we could add a default implementation to do what it does write now and leave the customization for the devs through DI. This is good for discussion, I can build a prototype as a POC |
Beta Was this translation helpful? Give feedback.
-
|
Please see this thread for more context: #1064 "The purpose of the Module Creator in the framework is to provide developers with a basic functional starting point for module development - so the fewer number of options the better or else it becomes confusing and defeats the intended purpose ( some would argue that even having 2 templates - Internal and External - is too confusing ). In addition, each new template requires ongoing maintenance as the framework is improved over time. My opinion is that it would be awesome to have a more advanced Module Creator... but it should not be in the core framework. It should be created as a custom module that can be installed through Module Management similar to the Blog module." |
Beta Was this translation helpful? Give feedback.
-
|
After thinking about this more, I think the Module Creator could be enhanced slightly to make it more dynamic and extensible. Essentially a "template" is group of files and folders stored under the Oqtane.Server/wwwroot/Modules/Templates folder. Currently there are 2 templates - Internal and External - but they are hardcoded in the Template selection in the UI. The Module Creator could be enhanced to display a list of all subfolders which exist in the Oqtane.Server/wwwroot/Modules/Templates folder. Then a developer could create their own custom template folder and it would be displayed as an option in the UI. With this enhancement, each developer can create and maintain their own custom templates. |
Beta Was this translation helpful? Give feedback.
-
From my point of view, I see that only developer himself/herself is responsible for customizing the templates. He knows what he did. Only he will maintain their own customization. There is no new maintenance effort on the framework level, because Framework offers only default Templates.
Yes, that could be great! |
Beta Was this translation helpful? Give feedback.
-
|
@vzdesic I have made some changes locally so that the Module Creator loads the list of templates dynamically ( based on whatever is defined under wwwroot/Modules/Templates ). I am interested in your opinion if the Internal template should be removed. Although it is possible to enhance Oqtane in this "internal" manner, it is NOT the recommended approach - so it seems like including this as supported option in the Module Creator is a bad idea. Your thoughts? |
Beta Was this translation helpful? Give feedback.
-
My opinion is that it seems like a completely logical step! For example, in my case, I want to have completely separated Oqtane.Framework solution from any code I write. That way, I will easily upgrade the Oqtane to any new version in any given moment without bothering about possible merge conflicts, potential braking changes or similar issues. At least, the probability is the lowest, and the fixing is the easiest that way. It seems like properly implemented separation of concerns. So, I personally would never create Internal Module, and I see and understand why it is NOT recommended approach. I cannot find any pros to implementing Internal Module. Still, if anyone wants to create Internal Module, he can do it, without code generator, manually. This way Oqtane is free from responsibilities for any damage, because person who did it really had a good reason for that and probably knows why he wants to do it that way. I hope this helps! |
Beta Was this translation helpful? Give feedback.
Please see this thread for more context: #1064
"The purpose of the Module Creator in the framework is to provide developers with a basic functional starting point for module development - so the fewer number of options the better or else it becomes confusing and defeats the intended purpose ( some would argue that even having 2 templates - Internal and External - is too confusing ). In addition, each new template requires ongoing maintenance as the framework is improved over time. My opinion is that it would be awesome to have a more advanced Module Creator... but it should not be in the core framework. It should be created as a custom module that can be installed through Module Managemen…