+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived Libraries & Helpers (https://forum.codeigniter.com/forumdisplay.php?fid=22)
+--- Thread: Matchbox RC2 (/showthread.php?tid=4444)
Matchbox RC2 - El Forum - 12-09-2007
[eluser]iive[/eluser]
sorry for my bad explanation.. let's me explain once again..
The goal I am trying to make is I want to make my modules as Modular as possible without needed any copy and paste work if I deploy it in another application.
So I have decided to put my modules folder in CI system directory so that it can shared among my applications. Basically I have a structure like this:
Frontend Application
system/application/site/controllers/Myblog.php (extends BlogController(blog.php) in my modules below)
Backend Application
system/application/admin/controllers/AdminBlog.php (extends BlogController(blog.php) in my modules below)
Modules
system/modules/blog/controllers/blog.php
system/modules/blog/models/blog_model.php
here is some code in site/controllers/Myblog.php
Code:
require_once(SHAREDMOD .'blog/controllers/blog.php');
class Blogs extends Blog {
function Blogs()
{
parent::Blog();
}
function index()
{
parent::index();
$this->layout('', 'Mago Blog', 'blog');
}
function entry(){
parent::entry();
$this->layout('', 'Mago Blog', 'blog');
}
function submitComment(){
parent::submitComment();
}
}and here is the code in modules/blog/controller/blog.php
Code:
class Blog extends Base {
function Blog()
{
parent::Base();
$this->load->library('forms');
$this->view->linkCSS('/assets/mago/css/blog.css');
$this->load->model('blog_post_model', 'blogpost');
$this->load->model('blog_comment_model', 'blogcmt');
}
function index()
{
$query = $this->blogpost->getAllPosts();
$posts_array = array();
// if there is post in the blog
if($query->num_rows() > 0){
foreach($query->result() as $key => $value){
$post = new BlogPost($value);
$posts_array[] = $post->render(get_class($this));
}
}
$view['posts'] = $posts_array;
// I use View Library and I put the view HTML code inside "content"
// and load it up in my ChildController(Myblog in my case) to display it
$this->view->set('content', $this->load->view('index', $view, TRUE));
}
// Other funtions here
}Am I make you clearer now ? I hope I did.. Thanks for the helps.
Matchbox RC2 - El Forum - 12-10-2007
[eluser]medium_kreation[/eluser]
how to call or load single/multiple modules in a default view...
below is y directory structure..
# MODULES
/application/modules/MOD_AUTH/CONTROLER/login.php
/application/modules/MOD_AUTH/VIEWS/login.php
#DEFAULT
/application/CONTROLER/site.php
/application/CONTROLER/admin.php
/application/VIEWS/site/index.php
/application/VIEWS/admin/index.php
now i want to call/include the MOD_AUTH/VIEWS/login.php (Login form),
into the default SITE & ADMIN pages for authentication and loging.
please suggest the process..
Matchbox RC2 - El Forum - 12-11-2007
[eluser]WolfgangA[/eluser]
Hello,
first of all i suggest to split this thread into a "Matchbox Support Thread" and a "Matchbox Design/Development Thread" to be able to follow discussions more easy.
The big picture
The big picture i see is to put Matchbox and the View libray together to implement a HMVC approach using codeignitor.
Moreover, this way the (H)MVC components should be really modular means: Can be added(installed) as extensions(modules) without touching the core application code.
Application design variants
Basically i see two major application design variants:
- Classic Web Application:
-- Upon start an "index" page is loaded
-- Each user action loads a new page (Click a link/menu, submit a form)
-- New loaded pages might have content in common.
- Web 2.0 XHR Style application (like using the EXT JS Library
-- Upon start a masterpage is loaded
-- Usally user action updates components in this masterpage using XHR, without loadind an entire page.
-- The masterpage can be replaced with another masterpage (unusal but possible)
Note: Of cause a "classic" page might use XHR / AJAX as well as a "Web 2.0" app might add iframes having classic content.
Classic Web application is covered quite well in CI, because each page can be controlled by its own controller.
(remeber CI actually does not allow to call "another controller" from "current controller")
But even in classic application design, if the developer tries tries to mimic an HMVC approach it becomes difficult. (Example: master page should be build upon parts(blocks) that are build as modules using their own controller)
These questions showed up a couple of times in the thread about "coolfactors View library" as well as in the thread of the former matchbox "modular seperation".
In a Web 2.0 XHR application this issue is even more visible. Why?
Because there is usually only a masterpage that builds upon several components.
What is a component in this sense: It is an entity that itself implements the characteristics of MVC (maybe even in the JS world). That is:
- it displays something (view)
- it needs some data (module)
- it decides what data to show or edit and how (controller)
A nice example of this would be a gridpanel using the EXT JS framework mentioned before.
So using an HMVC approach, the masterpage would be constructed by getting the necessary information from the MVC based entities (which itself should be able to query sub MVC entities, so they would be in fact HMVC entities as well)
In other words: The master page delegates the request to sub HMVC entities.
Now what has this to do with matchbox, module manager and the view library?
Well matchbox already allows the use "modules" which are a set of controller, libraries, helpers etc.
The View library already supports the idea of "parts". (However suffers from a namespace issue, but this is a different story)
So what would be the core role of a module manager?
- Initialize/Load module
- Asked module what to put into the master view
- delegate requests (from user interface, from other entities)
and this is pretty much what in my understanding an HMVC approach would look like.
If the above makes sense to you ...
Let's assume the above makes sense why not building the module manager in a way, that modules can be automatically loaded upon request.
(Sure there would be some overhead, but i do not see that will be an issue. Also that might only effect the load of the master view.)
This would truly allow to build modules that could be plugged in(installed), without touching the core application code.
So the benefit would be:
- Apps can be build truly modular. Modules can be seperate entities, even zipped archives that are expanded in a folder.
- Apps can be extended on the fly using a modules installer (whatever that looks like)
This would require that the module manager (together with the view library) is in fact the application. And the application would be a sort of master page / document manager for all the modules that provides individual functionallity.
(Again this looks to me like a HMVC approach)
Going further - thoughts on implementation
The module manager should provide an API to interface with modules.
To help, modules should contain a library (because a libray can be called from a controller), that is inherited from a template module class that contains abstract implementations of the necessary methods like init, install, deinstall, register, get_version, depends_on etc.
Also there must be methods to provide content for the master view or request resources like a menu or panel like get_content, request_resoure.
This way, the module manager would have an easy to maintain API to talk to modules and could be extended via sub classing.
Installation / Deinstallation
The module manager should provide an API that abstracts the installation process:
- get the module (from archive, from folder...)
- setup the module (check dependancies then delegate to module)
So how the module setup is finally done, depends on the module. (i.e , modify database, check permissions). This would be somehow similar to any LINUX based package management).
On top of this, the module manager could provide optional methods like activate/deactive a module.
Version checking
The modul manager should support version checking by design. Being aware of concerns that this would complicate module design i see this as an mandentary requirement when the application start growing.
Maybe the module manager can provide a function to ignore version checking for those that do not want to use it - however i would not recommend doing so. And, having an API using defined methods, that would not be as difficult to implement anyway.
Regards
Wolfgang
Matchbox RC2 - El Forum - 12-11-2007
[eluser]WolfgangA[/eluser]
More Thoughts on module installation / deinstallation
I have seen request for module manager to support a web interface and the like.
Well this should not be part of the MM, because it is GUI stuff that needs to be implemented in the application.
I think all is needed is an API.
More Thoughts on module manager implementation
[quote author="esra" date="1196922333"]This brings up some thoughts about a module and its dependencies in regards to the proposed module installer. In the least case, there should be a way of identifying module dependencies in the module package installed by the installer module--maybe the dependencies could be displayed in a message after the module is displayed.
I guess the other approach is to create a CodeIgniter installer module rather than a module installer. Then the installer module could install libraries, helpers, language, plugins, etc., allowing a module controller to perform discrete installs of the dependencies. But this gets into recording the dependencies associated with a module somewhere (probably, a database table) if the module needs to be uninstalled. Also, what if multiple modules use the same dependencies. Conceivably, a dependency could already be installed and when installing a module, there would need to be code to determine if any other modules used a dependency.[/quote]
I 2nd esra's approach.
- The module manager itself should be a module that is autoloaded.
- The module manager should support versioning and dependicies.
How this information is stored (db, file, config file) needs more thoughts and might be abstracted through an API.
Thoughts on pro / cons versioning and dependancies
[quote author="sophistry" date="1196995877"][quote author="esra" date="1196992730"]Generally, I think config file options with preset defaults are a good compromise for most of your arguments.[/quote]
hi esra,
actually, my main argument was keep it simple!
your needs are clearly different from a large portion of the CI world - you are one of the boundary pushers.
by all appearances you have some awesome coding and architecture chops. i respect that, but it also makes you a generally non-representative sample.
[/quote]
I agree with "keep it simple" and i disagree "with your needs are clearly different from a large portion of the CI world".
If any application grows, versioning and backwards-compatibilty will become an issue.
Instead of "use the latest version", i prefer a clear version scheme using a major minor concept as outlined before.
Given that each module would provide a module name (unique identifier), also dependencies would be easy to implement, so i really do not see why it would over complicate things.
Code:
$this->depends_on('mod_auth', '1', '0');
or
$this->depends_on = array(
array(module => 'mod_auth', major => '1', minor = '1'),
array(module => 'mod_session', major => '2', minor = '1')
)However it might be, that for example minor version 2 includes a bugfix of the release in monor version 1, so i suggest to add also the minor number.
[quote author="sophistry" date="1196995877"]
the points you raised do not satisfy this issue: there is no problem for this solution. imho, all this is solving (WRT non-CI external libs) is lessening the code footprint at the expense of simplicity.
i understand that modules will break as CI itself grows - that's why there's a CI constant CI_VERSION. and that is the responsibility of the module dev to check that const and keep the module up to date. however, my points were responding to the post about modules "sharing" external libraries.
i think that allowing module developers to set up (even config-driven, optional) dependencies is an awful idea because it actually *breaks* modular separation. think about that for a minute.[/quote]
I carefully read your post and it seems to me that the approach above would allow to adress the issues you mentioned without over complicating things. Especially i see benefits using "external" modules (which are in fact just modules), by ensuring compatibility based on versioning and functionallity based on dependancies.
So instead of "undefined property in xyz" the module manager could raise an error like:
"module abc requires module xyz in version a.b but module xyz is not installed"
or
"module abc requires module xyz in version a.b but module xyz has version c.d"
Important: All the above assumes that a version and a dependancy refers to a module as a set of files, that is including: libraries, helpers, controllers, views etc., not only a single part of it.
Regards
Wolfgang
Matchbox RC2 - El Forum - 12-13-2007
[eluser]WolfgangA[/eluser]
Maybe a bug in Matchbox 0.9.2:
From the docs:
Quote:If the controller have the same name as the module, the controller segment can be omitted, even if the controller is in a subfolder.
In the current release the controller segement _must_ be omitted if the controller has the same name as the module, it is not an option.
The reason lies in MY_Router.php arround line 214:
Code:
/**
* Validates the supplied segments
*
* @param array
* @return array
* @access private
*/
function _validate_request($segments)
{
// {{{ Matchbox
foreach($this->_matchbox->directory_array() as $directory) {
// URI in the form /module/controller/method where module_name != controller_name
if (count($segments) > 1 && $segments[0] !== $segments[1] && file_exists(APPPATH . $directory . '/' . $segments[0] . '/controllers/' . $segments[1] . EXT)) {
$this->_matchbox->set_directory($directory);
$this->_matchbox->set_module($segments[0]);
$segments = array_slice($segments, 1);
return $segments;
}
// URI in the form /controller/method where module_name == controller_name
// Works on /module/method but triggers and fails also on /module/controller/method because it leaves the first segment
if (file_exists(APPPATH . $directory . '/' . $segments[0] . '/controllers/' . $segments[0] . EXT)) {
$this->_matchbox->set_directory($directory);
$this->_matchbox->set_module($segments[0]);
return $segments;
}Given an url like /test/test/method, the first if clause fails to trigger and the next if clause triggers, but leaves the 3 segments in place.
Later on in Router.php, the second segment is treated as the method, which is obviously wrong. So CI calls the index() method of that controller if it exists.
To fix this the following worked for me:
Code:
function _validate_request($segments)
{
// {{{ Matchbox
foreach($this->_matchbox->directory_array() as $directory) {
// URI in the form /module/controller/method where module_name != controller_name
if (count($segments) > 1 && $segments[0] !== $segments[1] && file_exists(APPPATH . $directory . '/' . $segments[0] . '/controllers/' . $segments[1] . EXT)) {
$this->_matchbox->set_directory($directory);
$this->_matchbox->set_module($segments[0]);
$segments = array_slice($segments, 1);
return $segments;
}
// URI in the form /controller/method where module_name == controller_name
// Works on /controller/method but triggers also on /module/controller/method
if (file_exists(APPPATH . $directory . '/' . $segments[0] . '/controllers/' . $segments[0] . EXT)) {
$this->_matchbox->set_directory($directory);
$this->_matchbox->set_module($segments[0]);
// remove if called like /module/controller/method
if (count($segments) > 2)
{
$segments = array_slice($segments, 1);
}
return $segments;
}Regards
Wolfgang
Again this is great extension to CI :-)
Matchbox RC2 - El Forum - 12-14-2007
[eluser]Matthew Lanham[/eluser]
I have asked this question before, but didn't get a definitive answer:
How can i structure a module to include front-end and back-end (admin) functionality?
Hopefully in a way that say you have 10 modules with the structure of:
modules
- module1
- - admin
- - - views
- - - models
- - - etc...
- - frontend
- - - views
- - - models
- - - etc...
And by running the url:
http://www.somesite.com/admin
It can pull in the functionality of all 10 modules, or at least reference to those 10 modules....is this and how is this possible?
Many Thanks
Matchbox RC2 - El Forum - 12-15-2007
[eluser]WolfgangA[/eluser]
[quote author="swanweb" date="1197680091"]
How can i structure a module to include front-end and back-end (admin) functionality?
modules
- module1
- - admin
- - - views
- - - models
- - - etc...
- - frontend
- - - views
- - - models
- - - etc...
[/quote]
My understanding is that usually the design is:
modules/modulename/views
modules/modulename/models
... etc.
and not:
modules/modulename/submodule/views
modules/modulename/submodule/models
... etc.
Quote:And by running the url:Usually you call a module like:
http://www.somesite.com/admin
url/modulename/controller/method
and not like:
url/modulename
However, because
a.) a controller can have a default method (index)
b.) the controllername can be omnited if it has the same name as a module you can in fact do:
url/modulename
But only if you meet the requirements above.
Quote:It can pull in the functionality of all 10 modules, or at least reference to those 10 modules....is this and how is this possible?What is the definition of "functionality of all 10 modules"?
Usally you call a controller method, process data and return a view.
So do you mean something like:
Call "module/controller/method" which calls "anothermodule/controller/method" or "anothermodule/model" or "anothermodule/lib"?
If so, where and how do you want a view be returned?
Matchbox RC2 - El Forum - 12-15-2007
[eluser]Matthew Lanham[/eluser]
Basically i want to create a completely modular system for clients to use for websites, so thats why i want the admin and front-end to be as one module, that can be easily imported and working....
Matchbox RC2 - El Forum - 12-15-2007
[eluser]WolfgangA[/eluser]
[quote author="swanweb" date="1197746357"]Basically i want to create a completely modular system for clients to use for websites
...
...[/quote]
Basically i want to do the same, and that is why spent the time on writing my thoughts about a module manager implementation approach that somehow "ties" modules together.
In other words: I think what you might look for does actually not exist that way.
But maybe someone else can comment on this.
Matchbox RC2 - El Forum - 12-15-2007
[eluser]zdknudsen[/eluser]
There are a lot of interesting thoughts scattered around these few pages. I'm in a bit of a hurry right now and I want to read all of it at a time when I'm not this busy.
I've had a very quick look at the lot, though, and I have these few comments (expect some better responses sometime after christmas):
I'm going to set up a google discussion group for discussions about the development of Matchbox.
If I am to make a module guide that lets you browse and download modules it will be separate from the module manager.
Regarding separating front- and back-end functionality, there is a very simple and effecient way of doing it. Simply have a subfolder in your controllers directory called e.g. /admin. You'll then be able to access these controllers through www.example.com/subfolder/module/controller/method (even omitting the controller if its called the same as your module, like Wolfgang mentioned). I don't see why you'd also want to separate the remaining resources, seeing as the back-end usually uses the same libraries/models as the front-end.