Regarding the autoloading thing, I definitely prefer the second way. I actually consider applying blacklists and whitelists on the TPL callbacks, because currently it has no restrictions at all which is not very secure. Autoloading could be an addition to it.

Yeah, that's why I've been releasing a lot of plugings which work in the templates this way: {PHP|insert_me_anywhere('some_params')}. It requires some good reasoning though whether to make something global or for a fixed place only, so many plugs (especially the old ones which could not benefit from the new CoTemplate features) still work the old way.

It's a good practice and I use it too. But… It has a back (negative) side. If we use this style: «insert_me_anywhere» callbacks - we force to load bundle of code in advance, so we have pack of functions in global space that can be called never at all.

For example, lets see in «attach2» plugin (it's great itself but I speaking now about callback styles only). It always load `attach2.functions.php` in «global» hook. What does it mean - 23kb file loaded and adds 26 addition functions in global space. It's not terrible themself but it happend on all pages. More plugins - more junk loaded and waste resources.

And I think we have to choose solution from 2 ways:

1. Make core function «cot_load»:

   // Includes specified file
   // for parameters description see cot_incfile() function 
   function cot_load($name,$type,$part)
   {
     require_once cot_incfile($name,$type,$part);
   }

   Now we don't need to use «global» hook and load code always. We add {PHP|cot_load('attach2', 'plug')} in the beginning of desired TPL file, where {PHP|att_*} functions should be used.

2. Using functions autoload register:  our plugin («attach2» in this example) in «global» hook should register list of its function in global «autoload function register» (that Cototnti should provide), like this:

   $cot_autoload_functions['attach2.plug'] = array('att_add','att_check','att_count', … );

   Other magic happened in CoTemplate while parsing callbacks: it checks for function exists in global space, then if not exists it checks «autoload register» and includes required file.

And I preffered second one. So it should be simple to inplement, not crashed logic of use tpl callbacks, and can be done backward compatible in plugins.

Yeah, that's why I've been releasing a lot of plugings which work in the templates this way: {PHP|insert_me_anywhere('some_params')}. It requires some good reasoning though whether to make something global or for a fixed place only, so many plugs (especially the old ones which could not benefit from the new CoTemplate features) still work the old way.

That's a cool thing! Any real world use case examples?

Here's another idea that i never had time to implement: so we have N slots in configuration by default. Why not make an admin tool that would add any slots you need on demand, using its own table and making them available via global tags like {PHP.out.slots.my_super_slot}.

That would be a good one for some (personally I frequently use the slots). But wouldnt that in combination with making plugin tags availible too, make a it a more versetile tool? I never really liked the restrictions that many plugins have. Maybe an simple example is in order: Take the latest donations plugin for example. It only shows on the index. and when I want to display that for example in a certain list, I have to do crazy stuff to add it in there, whilst if it were possible to add it via a slots, it will be easy peasy to achieve.

Yeah, and i know that for the lot of you achieving that example is something you can do blind. But he, limited to html/css here, so yeah, I am always looking for ways to make my own life a bit easier, which with this neet little plugin already is helping (thank you Macik).  I for one am keeping my fingers crossed that this can be achieved..
 

Here's another idea that i never had time to implement: so we have N slots in configuration by default. Why not make an admin tool that would add any slots you need on demand, using its own table and making them available via global tags like {PHP.out.slots.my_super_slot}.

Main usage of menu slots is to easy maintain menu or common block of code for use in templates. But last trend for it is to use cot_* functions and makin «IF» blocks right in TPL files.
So user must choose to use web-editing with «plaintext» or to use file-editing with functions and tags.

Slot'n'Tags - is attempt to combine better of these ways.

ps: already added in downloads and being rewieved.

I added it on our Google+ page

Cotonti have a predefined custom tags that admin can use in templates. Content of these tags called «menu slots» can be altered via administration web interface. As a default, menu slots allow to use only simple html text. With this extension you can use common TPL tags and function calls like in TPL files.

Link:  http://macik.github.com/cot-slots_n_tags/