I'm curious about the design decisions in the module structure. I love the flexibility it offers, however it seems like there is quite a bit of coding required for things that could be inferred from sensible defaults and/or conventions. Take,
for example, the maps content part outlined in the
Writing a Content Part doc. I appreciate that, as a doc, it is showing off all of the parts of a module you might want to customize, however, as far as I know, none of the steps outlined could be left out. I'm sure there are very good reasons
as to why each piece is necessary, however I'd love some insight as to why that is so. So here are my thoughts:
I feel like this is the core of the ContentPart module, and obviously is necessary. I think that, by default, the getters/setters could have values injected/mapped to properties on the record of the same type and name, instead of having to directly
reference the underlying record.
Basically, I'm not sure if I understand why the record needs to be specified by default. I would think that between the model and the Migrations, you can infer a mapping from the database to the model in most scenarios. FluentNH provides very
powerful declarative mapping capabilities, and if the concern is not being tied too significantly to the data tier, then I would think another mapping solution could be adapted.
This is obviously required
I would expect there to be a default storagefilter for most objects declared in the migrations file as a default
I would expect these to perform the basic crud operations by default, with a common naming convention for the shape names and templates
I would expect this to leverage the MVC standard for inheriting displaytemplates and editortemplates (i.e. if there is no displaytemplate or editortemplate defined, it cascades down to a lower level for default templates for the property type)
I'm not sure what I would expect the default for this to be, however I would think that there would be some sensible defaults.
In summary, obviously a lot of thought has gone into this and I'm sure there are very good reasons for things being the way they are. I guess I'm just a little surprised at the level of complexity required for even a simple module. It's great to have
flexibility, however it seems like the barrier to entry is quite high currently, and the overhead is significant if you are building out a complex system with lots of different custom modules.
If I am incorrect in any way, please correct me - I'd love to learn more about the way orchard works. Otherwise, I'd also love to hear thoughts regarding these items.