[trendoman]

If you have any questions or wish to discuss how internal things work, I (and @KK, of course) can try to answer them.

Previously I was studying how CouchCMS works internally (PHP) when I coded new tags or modded existing ones or did other stuff. I am sure you do the same. I am interested in more systemic approach now. I am building a huge log of everything that goes on under the hood - to better imagine the battle field and know every piece in a nutshell. It demanded adding logging lines to the files and I do so in my mother tongue. I could later translate it to English, if anyone expresses a seriously motivated interest.

I will add Couch+PHP-related links to this topic and also what @KK explained to me in private about Couch nuances, which may be good for others to know.

P.S. I hope this topic be focused on how Couch's PHP objects, functions, fields and stuff intertwingle in PHP code solely.

Couch+Frontend PHP is *not* what this topic is about. I will add some links anyway for those who might have come here for it -

viewtopic.php?f=4&t=7594#p11751,
viewtopic.php?f=2&t=10763#p27318,
viewtopic.php?f=2&t=9882#p22669,
viewtopic.php?f=4&t=10627#p26647

[trendoman]

@KK, there is a suggestion -
Visiting backend, the function k_register_admin_routes() (file - K_SYSTEM_THEME_DIR . 'register.php') runs pretty early and retreives data of all templates from database. Couldn't this be a perfect spot to store this data in $FUNCS->cached_templates? Constructing an object of KWebpage class later could benefit from it and save request(s) to database. Please comment. Thanks.

[trendoman]

Once I needed to have my variables set inside a modded tag pair. In short, I needed a context $CTX. I managed to do it with some calls, however decided to ask Kamran, here is his reply verbatim -

---
Normally you don't have to set the context yourself - Couch does it for you if you have registered the tag as having context.

If you take a look at how register_tag() function is defined, you'll see the third and fourth parameters as optional -

Code: Select all

function register_tag( $tagname, $handler, $supports_scope=0, $supports_zebra=0 ){

Setting the third one to '1' will take care of handling the context for you e.g. this is how cms:mosaic is registered

Code: Select all

$FUNCS->register_tag( 'mosaic', array('KMosaic', 'tag_handler'), 1, 0 );

If your tag want's to support 'zebra' as well (this is required when the tag executes its enclosed contents multiple times e.g. cms:pages, cms:show_repeatable etc. you can set the last parameter to 1 as well e.g. cms:show:mosiac

Code: Select all

$FUNCS->register_tag( 'show_mosaic', array('KMosaic', 'show_handler'), 1, 1 );

For rare cases where you do wish to manipulate the context stack manually, you may use the $CTX->push() yourself but then make sure to use $CTX->pop as many times as the pushes or you'll leave the stack in an invalid state.

--

Next, I will try to post more on an undocumented editable type 'single_check' which can be found (and used) in Couch code.

[trendoman]

@KK, another suggestion (please, give a feedback on the first one?) -
When Couch renders 'template_missing', context-setter function _render_template_missing performs a DB request to find lasting pages. This request doesn't need all ids of all pages, only count of them, does it? So, the request can be optimized and slowness avoided (however minuscule the feature it adds to quality of software).

[KK]

@trendoman, yes, indeed, these could be possible optimizations.
Do let the suggestions keep coming in.

[trendoman]

@KK, It would help having more __toString() methods to dump $FUNCS object - in following mandatory classes: EventDispatcher, Route, KNestable.

[trendoman]

Do let the suggestions keep coming in.

Only if you tolerate (and defeat in comments) those that come from my taste. Some (rare) suggestions are born simply out of "I would have done it differently" without an immediate improvement to measurable qualities of code. For instance, method $FUNCS->add_admin_action naturally itself could add a menuitem to $FUNCS->admin_actions[]. Instead, the method calls $FUNCS->_register_menuitem(), which merely builds a menuitem. This is where I would have a $FUNCS->_build_menuitem returning menuitem back to add_admin_action(), which would naturally add it into admin_actions[].

P.S. It's not about renaming. It's about (1) comments to my posts (2) expressing my feelings about code which often feels atomized and hard to grasp into the big picture. Even with a full log, menuitem concept (and KPagesAdmin->form_action() in general) too slowly soaks into perception.

Talking about how Couch works, let me say I've been using CouchCMS for like 5 years I think, and I love it.
I had to re-design a few things, naturally ended up editing the core functions among other things.

The only thing I'd love to see in the future is some improvements in the base code, you know it's kind of spaghetti code right now. Rewriting it, adding support so that coders can easily understand how it works would be awesome.

Well, that and a PR campaign. CouchCMS is great and very underrated. I've met quite a few designers banging their heads against the wall trying to create a simple site, and they didn't know about Couch.

Awesome work KK.

[trendoman]

The only thing I'd love to see in the future is some improvements in the base code, you know it's kind of spaghetti code right now. Rewriting it, adding support so that coders can easily understand how it works would be awesome.

You don't understand what you are talking about.

Extending Couch (if one knows what she's doing) is very easy. Rewriting of core code is almost never an option. CouchCMS code is so good that one can learn good coding manners out of it and it can serve an example introduction to OOP.

[trendoman]

Kamran,
Could you please help me understand - I see that quite often Context level is added with an empty first param (name):

Code: Select all

$CTX->push( (string) "", 0)