Hey Colin, awesome work on this release.  I love the fact that I can extend this to add to it without having to screw around with the actual library.  Keep up the awesome work!

Hello i think i found a bug..
(version 1.4.0, but maybe also reproducible using version 1.4.1 since it use the same core like you said)

Here is the example how to:

i have 2 region which is content and sidebar.

Then in Controller (ex: hello.php)

Then in View (sidebar.php)

The bug is:
You can use $data_content variable(in this case $hello) even it wasn’t passed into sidebar view.

This might become a problem if i am passing the same variable name, isset function will return true even actually the variable wasn’t passed into the view.

Thank you

I use this lib but I do not see how to use this with CI modules, because the path to Views is static to application/views/ and the modules of CI are application/modules/  the Views of the modules are somemodule/views.

Some body have the same problem?

@Randy: First off, thanks for the kind words. I think I see where you are going with add_region() but I don’t know… I’m not thinking very logically tonight The placement of regions is provided by the master_template, with receives the regions as variables, like a classic view. If you wanted the added region to output above $footer, you would simply shift it “above” footer in the template’s markup. I have a feeling we are on different pages… Feel free to discuss it more.

@Too Pixel:

This mean I can overide your library using a MY_Template.php file, right? Out of this point, what are the benefits to have a library as a core class?

Namespacing in this manner should always be followed, and the only namespace I can rely on, given CodeIgniter’s set conventions, is prefixing libraries with “CI_”. And yes, this has the added effect of being able to override it like a core class. That’s one benefit. The other benefit is something I actually noticed when debugging this release. I created a controller called “Template” to add test code to, and you can imagine the problem that caused: Fatal error: Cannot redefine class “Template”. That’s reason number two.

I think naming custom Libraries “CI_Library” is a general rule you should follow, especially if you intend to share it.

@dexcell:

The bug is:
You can use $data_content variable(in this case $hello) even it wasn’t passed into sidebar view.

This is the nature of CI, it’s Views system, and “embedding” Views. Many people actually see it as a feature, not a bug. Don’t fear name clashes, because if your ‘sidebar’ View was explicitly passed a $hello variable, it would in affect override the ‘content’ View’s $hello variable. Again, CI takes care of this, and Template is just a “wrapper” for CI Views.

@AgentPhoenix:  Thanks! Working on 1.5/2.0 (depending on how much goes into it) at the moment.

I use this lib but I do not see how to use this with CI modules, because the path to Views is static to application/views/ and the modules of CI are application/modules/  the Views of the modules are somemodule/views.

Some body have the same problem?

Template was designed to work with CI, not necessarily CI + modular solutions. Template follows CI’s conventions strictly, and by necessity, solutions like ME - HMVC subvert these conventions.

With that said, I have had users confirm that they were able to get Template and ME - HMVC working together swimmingly. I am considering implementing a “compatibility mode” that will work swimmingly with these modular solutions, but that requires diving into them and figuring them out, which isn’t exactly what I want to do at this point. Search “Template Library Version 1.4.0” and read through that thread where this issue was discussed.

Colin Williams - 10 November 2008 04:54 AM

I use this lib but I do not see how to use this with CI modules, because the path to Views is static to application/views/ and the modules of CI are application/modules/  the Views of the modules are somemodule/views.

Some body have the same problem?

Template was designed to work with CI, not necessarily CI + modular solutions. Template follows CI’s conventions strictly, and by necessity, solutions like ME - HMVC subvert these conventions.

With that said, I have had users confirm that they were able to get Template and ME - HMVC working together swimmingly. I am considering implementing a “compatibility mode” that will work swimmingly with these modular solutions, but that requires diving into them and figuring them out, which isn’t exactly what I want to do at this point. Search “Template Library Version 1.4.0” and read through that thread where this issue was discussed.

How about including the cascaded file search like ME? So if you have something like this:

Where as you have to be in the “System” module to get access to the one.tpl file. I’m sorry if I don’t make scene, I can explain better if needed.

@milos - it really isn’t that dramatic.  I’ve simply overridden Loader with a simple module loader method that looks a modules folder.  It’s very straight forward and has fewer hassles than the hierarchy tree searches.  It is less flexible though.

I’ll post it if you’re interested.

Randy

The only place it should theoretically break down is when it’s cascading through suggested view files. Otherwise, it just calls $this->load->view(), which ought to work as expected with any situation. If a third party solution overrides how Views are loading, that introduces too much change, in my opinion.

@Randy: If you have a solution for ME5 please post
@Colin: It would be very useful as many people are going towards the use of a HMVC (or partially).

Thanks Colin for the answer, yeah namespacing is a good argument, I’ll start using CI_Somelib too for some libs. Keep us the good work !