Hi Kamran and people,
A quick feedback on the 'theming' of Couch. Context-setters (PHP functions) create variables that are used in render. For most users their names are random and, in sharp contrast to system-wide variables, they pop-up from nowhere despite sharing the same 'k_' prefix. This initially discouraged me from adopting Couch 2.0, because nothing was clear from the first look at the code unlike what Couch tried to convey. Almost each snippet in /couch/theme/_system/ has variables that mean nothing outside of that snippet.
My suggestions to the theme-variables are (1) to have another prefix, different from system-wide reusable variables - this would emphasize their temporary and specific nature (2) possibly ditch them altogether and replace with a single simply-named variable that will be used in all context-setters and would represent an array of all custom values. We could have a simple and short name, for example th_vars.
Let's see a simplest snippet in the theme folder - 'theme/_system/alert.html'. With 'th_vars' it would be explained that all values one passes to a renderable snippet are simply an associative array inside the th_vars variable. Anyone could quickly peak into that variable (<cms:show> as json) and immediately see all possible values a coder had designed for the renderable. One would be able to use those values directly like 'th_vars.alert_type' or define a new variable in the snippet itself, (my_alert_type = th_vars.alert_type).
I am already using this approach in part for my custom renderables. I have a tag that allows to customize message in admin panel (based on cms:show_info) and I called that super-variable in my context-setter a 'k_alert' for simplicity. By this I allow anyone who studies or improves my code peek into 'k_alert', see the array with all registered values, choose whatever they need and use them at once e.g. k_alert.icon, k_alert.heading, k_alert.content etc. I don't use a super-famous single-named variable yet, because I am looking into more experience with this approach. That's why I named it 'k_alert' and not another name yet.
I find this approach more transparent, easy to follow and study. Maybe it will be even easier if such single variable had a name of the snippet itself, like k_content_list_inner - but this is a last-minute idea that just popped up as I am concluding this post.
A quick feedback on the 'theming' of Couch. Context-setters (PHP functions) create variables that are used in render. For most users their names are random and, in sharp contrast to system-wide variables, they pop-up from nowhere despite sharing the same 'k_' prefix. This initially discouraged me from adopting Couch 2.0, because nothing was clear from the first look at the code unlike what Couch tried to convey. Almost each snippet in /couch/theme/_system/ has variables that mean nothing outside of that snippet.
My suggestions to the theme-variables are (1) to have another prefix, different from system-wide reusable variables - this would emphasize their temporary and specific nature (2) possibly ditch them altogether and replace with a single simply-named variable that will be used in all context-setters and would represent an array of all custom values. We could have a simple and short name, for example th_vars.
Let's see a simplest snippet in the theme folder - 'theme/_system/alert.html'. With 'th_vars' it would be explained that all values one passes to a renderable snippet are simply an associative array inside the th_vars variable. Anyone could quickly peak into that variable (<cms:show> as json) and immediately see all possible values a coder had designed for the renderable. One would be able to use those values directly like 'th_vars.alert_type' or define a new variable in the snippet itself, (my_alert_type = th_vars.alert_type).
I am already using this approach in part for my custom renderables. I have a tag that allows to customize message in admin panel (based on cms:show_info) and I called that super-variable in my context-setter a 'k_alert' for simplicity. By this I allow anyone who studies or improves my code peek into 'k_alert', see the array with all registered values, choose whatever they need and use them at once e.g. k_alert.icon, k_alert.heading, k_alert.content etc. I don't use a super-famous single-named variable yet, because I am looking into more experience with this approach. That's why I named it 'k_alert' and not another name yet.
I find this approach more transparent, easy to follow and study. Maybe it will be even easier if such single variable had a name of the snippet itself, like k_content_list_inner - but this is a last-minute idea that just popped up as I am concluding this post.
