Welcome Guest, Not a member yet? Register   Sign In
Nested MVC
#1

[eluser]BizComputing[/eluser]
Was thinking how I could add value to the CI community and thought about something I am currently working on. Sorry, the code is proprietary and still under development, but there is enough in place for proof of concept. Once the code is done, I may be able to convert it to a more generic version that I can release to the community.

My reason for this post though is to throw the idea out there in case someone wants to work on their own implementation, or to draw out others that may have come up with other ideas to deal with nested MVC.

So, here's the idea.

Create base sub_controller class which provides methods for index, submit, validate, and save. Index method used for building the page via a view, submit method used for handling forms, validate for checking validity of data, save for saving data. Validate and Save provided as seperate methods for cases where master controller may be responsible for validation and save of sub-controllers.

This base sub_controller would be loaded via either load_class function, or require/include, or as in my case, via a customized loader->library which allows for setting instantiation to false.

Sub_controllers would then be created extending the base sub_controller, the base sub_controllers constructor takes care of initializing sub_controller reference to the base controller. Use of sub_controller would proceed as you would via a controller, except, rather than loading models and views against itself, the sub_controller would need to call into the base controller.

Base controller would be responsible for loading sub_controllers and calling the various sub_controller methods at the appropriate times.

My implementation actually provides an additional folder off the application folder to hold these sub_controllers. This allows for a distinct functional seperation between controllers, sub_controllers, and libraries. I actually extended the loader class to load my sub_controllers from this folder as well as ensuring that the super class (base sub_controller) definition is also loaded.

As I said, nothing I can share codewise at this time, but thought the ideas might be useful to the community.
#2

[eluser]wiredesignz[/eluser]
Quote:Base controller would be responsible for loading sub_controllers and calling the various sub_controller methods

sub_controllers sound a lot like libraries to me.
#3

[eluser]BizComputing[/eluser]
Yes, sub_controllers are libraries and that's why they load like libraries. They are special purposed libaries though in that they have a predefined structure specific for calling their own model(s) and view(s).

There is nothing I am doing in sub_controllers that can't be done currently with plain-jane libraries. My purpose in sub_controllers is organization. I have "modules" that provide a view interface with a specific subset of data, validate a specific way etc. and can be used with a few controllers. The original application (not written on CI) had this code duplicated in each "screen" that needed this functionality. At some point in time, that duplication of code was noticed and partitioned out into it's own callable module. I am simply recreating this ability in CI.

What these sub_controllers give me is organization. I deal in projects that have a few hundred php files. As I move to CI, I see that number of files growing as I break up the files I currently have into their MVC components. I would rather take my special purpose libraries and deploy them in a different folder, give them a name that associates best with their specific purpose. Additionally my modifications to the loader libary allows auto loading of the base class without instantiation or having to remember every time I load a sub_controller that I have to have previously loaded the base class.

There is a precedent here, search thru the forums and you will see, I'm not the only one interested in such an idea. I am not asking for a change to CI, CI is great the way it is. But, in the spirit of a framework, especially a lightweight framework such as CI, it falls to the community to develop specializations of that framework. Newbies adopting the framework then have available a plethera of specializations they can pick and choose from that best matches what they are trying to get done.
#4

[eluser]sikkle[/eluser]
Humm, maybe i'm wrong, but you may want to give a look to something call matchbox, not sure if it's what you mean.

good luck !
#5

[eluser]BizComputing[/eluser]
I may be completely wrong here, but I did a quick lookup on matchbox, and it seems to be meeting the need of nested views, not nested MVC. Nested MVC to me means that I have a controller, view(s), model(s) that fufill a reusable fragment, totally selfcontained. This can be used either as optional extensions to an existing controller and it's views, and it's models or it can be used as a "plugin" where multiple controllers, views, models share a common feature. In the first use case, if an application is configured with these options off, then you are saving having to load all the programming associated with the module, the only code that is still loaded is the interfacing code in the calling controller. In the second use case, you are saving on the duplication of effort where you have a chunk of "screen" and it's associated code that can be used from multiple other "screens".

An example:

Case 1:
A group/workflow application where you have an entity that represents the "document" being worked on. Based on where the document is in the workflow, you have different actions that can take place. Also depending on the logged in user, some actions may not be available to them. In a traditional PHP app, your programming for the document loads all the code for all the various actions, the forms, the fields, the controlling code etc. In a complicated workflow application, this can be substantial, and at any point in time, only 10% of those actions may be in actual use. By breaking off these actions ( both visuals(view) and code(controller) and supporting data services(model) ) into modules, you then only need to load the actions that are effective for this session as well as loading the basic code that determines which actions are effective and loading them.

Case 2:
You have an address module that lists and allows entry of new addresses. These addresses can be part of a client maint screen, or a customer maint screen, or a user maint screen, or a contact maint screen, or a vendor maint screen, or... Rather than coding this address servicing code and display code in each maint screen, once again a module would save on coding. Each maint screen would only have the code for loading and interfacing with the address module. The address module would be responsible for delivery of it's portion of the view and managing it's own data via it's own model.

Each of these cases can be done via a library for the module controller code, and the library can load a view(s) for the modules portion of the screen, and the library can load a model(s) for it's portion of data services. The models and views used by the library are loaded via the controller the library is attached to. So, my idea here which is already mostly implemented in my application does not do anything you can't already do with CI right out of the box. The idea is simply a way of specializing these libraries so they are automatically handled slightly different than standard libs ( by allowing loading these specialized libraries from a different folder off application folder, and by automatically loading the class definition that gives all these sub_controllers a standard interface ). And the reasoning for handling these specialized libraries differently are for the purpose of additional organization of code ( very important to me considering the size of the applications I manage ), and simplifying the loading of these specialized libraries where I the programmer don't have to remember that every time I load one of these libraries I need to make sure the super class for these libraries are included/required.

It seems to me based on the responses I've received so far for this is that I'm working on something that others don't really need. That's ok, I needed it, I coded it, I'm nearly finished with the proprietary implementation. I just thot that there may be others in the CI community that may benefit from this idea, and if there were, then I would possibly go the extra mile to convert my proprietary implementation into an open implementation and make it available to the community. Hey, it's ok if no one needs this, heck, it saves me the time of genericizing the idea for sharing.
#6

[eluser]sikkle[/eluser]
Humm not so sure, from what i see : controllers, libraries, views, are supported by matchbox.

maybe a time saver to keep looking.

but still always good to see new implementation and let the community talk !
#7

[eluser]BizComputing[/eluser]
Must be my stupid day, it is Friday, so, that's my excuse. Anyhow, browsing the docs for matchbox, I don't see the nested MVC concept represented. I only see a different way to organize your resources. What I'm talking here is having more than 1 controller in memory at the same time with associated resources. It's not really more than 1 controller, it's simulated via a very simple mechanism.
#8

[eluser]xwero[/eluser]
I think you are talking about HMVC. It would be great to have that option in CI. It would make tracking bugs so much easier and no more extending the controller to make layouts.

If you want to share this code it would be a gift from heaven Smile
#9

[eluser]BizComputing[/eluser]
Yes, I've heard what I'm simulating here as HMVC. Keyword and tricky phrase "simulating". My sub_controllers or child_controllers or whatever you want to call them are really just libaries temporarily extending the functionality of the hosting controller. The hosting controller is the only real controller and is the controller responsible for loading all the resources.

What I have coded up to now is proprietary code. I can share the code once I genericize it, but with how busy I am, I will only tackle the genericizm if there is enough interest in it. So far I've apparently either communicated poorly what I am doing, or, I've failed to attract those that would benefit from such an idea.
#10

[eluser]BizComputing[/eluser]
OK, I just got confirmation from Zacharias, the author of Matchbox. Matchbox does not address what I'm addressing here. So, I'm not missing matchboxes point but somehow failing miserably at communicating what I am doing. Oh well, weekend ahead, go big blue.




Theme © iAndrew 2016 - Forum software by © MyBB