I would love to see a full explanation of the differences in developing new modules starting from a recipe or from a proper module.
Using a recipe to create new content type with new fields and views is very handy. Using that recipe to start adding new functionality within the .module file makes me see it a way of a faster module developing, but I would like to know what are the caveats of this approaching in terms of updating the content type, for instance. Couldn't it be updated anyway with a hook_update in the .install file? Is there any other aspect of module developing I should consider before deciding to use a recipe as a base of a new module?
Thanks!
Comments
@robertgarrigos - Interesting question. I don't think I've thought about using recipes as a starting point for a new module yet.
Let me be sure I understand the question correctly. I think you are suggesting that you might create a module that depends upon a recipe to create the content types and views that will be used by the module and are wondering about the implications of that?
I don't know of anyone that has tried this yet. In theory, I think it should work fine. If you make a module dependent upon a recipe, I believe that the recipe will be installed first and that everything you need will be present before the module is installed. In theory, a useful tool.
Some things to be concerned about. Recipes are not intended to be updated, once they are installed you use them as they are at the time of installation, but you are not able to update them in the future to get new features added to a recipe. This means that a recipe creator has the flexibility of making major changes in a recipe that might not be backward compatible. Which also means, that in theory a maintainer might make changes in their recipe that your module does not anticipate and that your module and the recipe may not always be compatible in the future.
This might not be a problem, if your module requires a specific version of the recipe and uses only that version rather than the most recent version. We might also make some decisions about recipes that prevent this kind of problem, now that we know it might be a problem. I will be asking others about this use case and how we can prevent conflicts.
I have definitely considered that recipes and install profiles might depend upon recipes, but had not yet considered the implications that another module might depend upon a recipe and how to make sure that is a reliable and stable relationship. Interesting.
Actually, I've already created a module (for a client), not dependent on a recipe, but created as a recipe. This means that I created the content type, configured its fields and added some views in the backdrop frontend, exported the config files and included in the config directory of the module, and then added some functionality within the .module file, just as a normal module.
I find this a much faster way of creating a module which deals with custom content, fields and views.
Of course, there must be drawbacks compared to creating a module with custom content in the proper way. I just would like to discuss them. Maybe in the next Backdrop live?
@robertgarrigos
I understand now. In terms of using config files as a shortcut to building content types, fields, and views - I think that you are good and don't need to worry about that.
Backdrop CORE using config in that way in the standard install profile and I BELIEVE that I've seen other modules do it as well. Certainly, the entire premise of recipes is based upon an ability to load config files in that way.
I suppose the one thing to watch out for is name-spacing. If you enable a module and it tries to create a content type, but one already exists with that name, it will do nothing and I believe it will report nothing. It will silently, not create your new content type, field or view. The one that exists will be fine, but the existing content type might not meet the requirements of your module.
There is currently, no way to modify an existing config file, without writing PHP.
So, just be sure to name your content types, views, and fields something unique enough to make sure that you dont' have this problem (if this is a potential problem for your module).
Does this make sense?
I look forward to discuss recipes with you at Backdrop LIVE or any other day of the week. :-)