robertgarrigos's picture

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

@ - 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.

robertgarrigos's picture

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?