I would like to be able to show a partial view of a module.  Example: a module whose job is to manage a calendar - allow the user to assign appointments to dates, tick them off and so on.  It would be good to have a mini-view of the calendar on the sidebar, but managed and controlled by the calendar controller.  I’m thinking of each controller having callback functions and each module having hooks (not CI hooks). 

I’ve read through dynazack -> zawk -> zacharias’ modular separation thread (http://ellislab.com/forums/viewthread/46669/), and also the mini-controller idea floated by Rick Jolly (http://ellislab.com/forums/viewthread/58405/) and would guess I’m after a blend of the two.  The issue is that it would be good to retain the modular separation (application/modules/<...>) without adding an extra library into application (application/libraries/<...>).

So:
1) Is it possible to have application/modules/<module>/libraries as is?
2) If not, is it possible to setup application/modules/<module>/libraries in zacharias’ modular separation code?
3) If not, is it possible to call a controller from another controller?
4) If not, would extending the base controller be of any use?
5) Am I making any sense at all?

Many thanks,
df

1/2) No, it is not possible to use libraries with my modular seperation as of now. But look back in the thread in a couple of hours/days.
3/4) I know others have asked those very questions before, try searching (again?).
5) I’d go with yes.

Cheers,
Zacharias

Actually, how about you and check it out right now? (Just added functionality for libraries among other things)

You’re The King zacharias!  Many thanks.

Cheers,
dfau

You are welcome.

Please let me know if something does not work as suspected (or does not work at all).

dfau - 07 September 2007 05:40 AM

I would like to be able to show a partial view of a module.  Example: a module whose job is to manage a calendar - allow the user to assign appointments to dates, tick them off and so on.  It would be good to have a mini-view of the calendar on the sidebar, but managed and controlled by the calendar controller.  I’m thinking of each controller having callback functions and each module having hooks (not CI hooks). 

I’ve read through dynazack -> zawk -> zacharias’ modular separation thread (http://ellislab.com/forums/viewthread/46669/), and also the mini-controller idea floated by Rick Jolly (http://ellislab.com/forums/viewthread/58405/) and would guess I’m after a blend of the two.  The issue is that it would be good to retain the modular separation (application/modules/<...>) without adding an extra library into application (application/libraries/<...>).

So:
1) Is it possible to have application/modules/<module>/libraries as is?
2) If not, is it possible to setup application/modules/<module>/libraries in zacharias’ modular separation code?
3) If not, is it possible to call a controller from another controller?
4) If not, would extending the base controller be of any use?
5) Am I making any sense at all?

Many thanks,
df

@Zacharias… this is a separate issue that effects how certain kinds of views are loaded by Loader. At the moment, the view method blindly loads view files with no knowledge of the view flavor (module-related view, block view, empty container for storing blocks, component view, etc.). As you know, the view method basically loads files from fixed directory paths. This is actually a good thing from an OOP standpoint, because it allows the view method to be modified to handle different flavors of views using additional methods. Modular separation is one aspect of creating a CMF-like set of extensions to run on top of CI. Block and component handling is a separate issue that probably needs to be addressed using a modified version of the modular separation Loader in combination with a View library (In my opinion, Coolfactor’s View library comes closest to solving the problem). Combining Modular Separation with a solution to the second issue should result in a more complete CMF-like set of extensions for CI.

@dfau… Rick Jolly started a separate thread on the second issue. You might try to find it because it tosses around some ideas for supporting blocks. The current method of handling blocks used by most people is to create a separate block-specific helper to handle the controller and model specific code. This works, but some more elegant MVC-like solutions are needed to develop a more consistent/versatile solution.

Attempting to handle block loading from an Application Controller (base controller) makes the block dependent on that controller. For installation/uninstallation reasons, it’s better for the block to be a separate entity with its own files stored in a separate directory structure. This is possible using the helper approach mentioned above but it breaks MVC in the sense that the model code is stored in the helper.

I’m trying to develop a new solution based on the use of a Block controller which is autoloaded by a block_view method. The Block controller supports models, so this completes the MVC triad. More about this later after work on the current suite of modular separation releases slows down a bit.

I’m not sure I fully understand the problem (or the proposed solution). I understand he wants to have a controller do the calendar work and so I thought the problem would be to include that controller from another controller. But how does the views have any effect on this?

I believe that most of the developers who are using modular separation are attempting to create a CMF-like (content management framework) set of extensions for CI. This is the framework style used by most CMS or portal systems. In a CMF, modules, blocks, and templates are usually separate entities stored in their own directory structures like so.

module/
modules/modulename/controllers/
modules/modulename/models/
modules/modulename/views/

blocks/
blocks/blockname/controllers/
blocks/blockname/models/
blocks/blockname/views/

templates/
templates/templatename/index.php
templates/templatename/js/template.js
templates/templatename/css/template.css
templates/templatename/images/image.png

CI treats module-specific views, block views, component views (widgets like trees or grids), and templates as a single entity called a view. Loader simply loads views from whatever search paths are supported by the view method. Part of the solution to this problem (which might not be a problem for all) is to make a distinction between module, block and template views in Loader and load the views from separate directory paths. This is fairly easy to do by adding additional search paths to the Loader’s view method.

Modular separation solves the problem of storing module resources in their own directory structures but does not solve the problems of storing blocks and/or templates in separate directory structures.

A block in a CMF is an independent entity with its own controller and model code. For example, you might have a login block appearing within the left column of a template. (Actually, you would also want to have a corresponding login module for redirects from other modules.) This login block could contain its own independent code for handling login operations or it could use methods from an accompanying module or library. Before MVC, this was fairly easy to do using procedural approaches—the controller, model, and view code was encapsulated in one or more files. To do this with MVC and provide proper code separation, this is usually handled by loading a block view and calling functions from a dedicated helper. The helper could contain the business logic code if required.

The reasoning for storing templates in separate directory structures is because in a CMF, you might need to use separate templates and/or themes for certain purposes. There are many reasons for this. One is customizing a site for a particular user by allowing the end user to select a specific template from a block. This is a popular thing on gaiming sites and community sites. Another issue is WAG compliance where certain colors might need to be displayed on a template to allow someone with color blindness to see template areas better. Or you might want to display a custom template for someone who was using a touch screen pointing device (e.g., a parapalegic or quadraplegic). Another issue is providing different template layouts for selected modules. For example, you might want to have some module controllers load templates with a menu block in a right or left columns, but use a separate horizontal menu block without left or right columns for a template designed for a forum where a wider screen display is preferred. In these cases, the preferred template for a specific module could be loaded from the module’s controllers.

You designed modular separation to meet your own needs, but some users are attempting to extend the approach to do the above. It’s not a big deal to modify the existing modular separation code to meet the above objectives. It’s more a matter of showing some examples as to how to do it. Modifying MY_Loader’s view methods is the best place to handle the above, thus the conversation you see in the original thread and this thread about handling those needs.