Last active
December 10, 2015 14:58
-
-
Save arjan/4450884 to your computer and use it in GitHub Desktop.
rebarizing zotonic
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Make each module and each site an Erlang (library) app. | |
| This means that each module should be structured like this: | |
| ├── dispatch | |
| ├── ebin | |
| ├── lib | |
| │ ├── css | |
| │ ├── images | |
| ├── src | |
| │ ├── actions | |
| │ ├── controllers | |
| │ ├── filters | |
| │ ├── scomps | |
| │ ├── services | |
| │ ├── support | |
| │ └── validators | |
| ├── templates | |
| │ ├── phone | |
| │ ├── tablet | |
| │ ├── tests | |
| │ └── text | |
| ├── tests | |
| └── translations | |
| └── template | |
| This way, modules and sites compile with the rebar {subdirs} feature. |
Sounds very logical.
Some thoughts. Some modules can have deps of their own, so you probably need a dep directory too.
Who will be responsible for scanning (and compiling) the templates? Handing over the dispatch table, translations and stuff from the lib dir? The zotonic app could do that itself by calling code:priv_dir(mod_base) and use that as a starting point to collect what it needs. We could also let the module apps do that with the help of core library calls.
Nice!
+1 for letting the modules do it with the help of calls to the core functions. This way, the paths need not be fixed indefinetly, since you can pass in a starting point and other options, per module.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We can even move templates, translations, dispatch into priv/