Module Creation Overhead

Topics: Writing modules
May 2, 2011 at 8:52 PM

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:

Model (Part)

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.  

Model (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.


May 2, 2011 at 9:06 PM

Can't say you're wrong here, and our own thinking for future simplification goes into the same direction. We did flexibility first and are planning on adding layers of simplicity, because we feel that's the right order... Stay tuned for improvements to this development story in the future.