What are some good reasons to create your own module/content types/parts etc. via code? #17546
-
I have been using orchard core for roughly 2 months now and one thing I don't quite get yet is when it would actually be ideal to create your own modules via code rather than via the UI. I have only had one rare exception where the functionality I needed wasn't available through the admin UI but I feel like a lot of things can be done from the admin UI. Another thing I figured was reusability but using the admin UI you can easily import and export content, settings, modules etc etc. So aside from some rare edge cases where you require unavailable functionality, what are some additional good reasons why you would choose to make one in code over using the admin UI. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
You need to roll out your custom module if its functionality is not built into OC :). There's not much more to it. Reusability is a good point, but as you also observe, recipes can serve as the vehicle to reuse custom content types and parts, and BTW even templates written from the admin (and Media files, and settings..). If what you need is possible with these, and you're happy to use them, then feel free to keep using them. My preference is to keep custom content types in code (in migrations), since then they can be versioned and easily shared as code. This is important if you work in a team, and/or on an app that you intend to maintain for years. Same for custom content types, although when I talk about "custom content types", then it's always about more customization than just adding fields, it's also about adding functionality in C#. |
Beta Was this translation helpful? Give feedback.
You need to roll out your custom module if its functionality is not built into OC :). There's not much more to it.
Reusability is a good point, but as you also observe, recipes can serve as the vehicle to reuse custom content types and parts, and BTW even templates written from the admin (and Media files, and settings..). If what you need is possible with these, and you're happy to use them, then feel free to keep using them.
My preference is to keep custom content types in code (in migrations), since then they can be versioned and easily shared as code. This is important if you work in a team, and/or on an app that you intend to maintain for years. Same for custom content types, although…