Thread

Hello,

  Should scaffolding work with Matchbox? (ver 0.9.2)  I’m new to CI so it’s entirely possible that I’m doing something wrong, but I have it working on a non-matchbox install. 

eg:  I have a ‘news’ module and it’s functioning within the module/class/function layout.  Although when I enable scaffolding, it never works. (same ‘news’ class under stock CI works)

uri of: site.com/index.php/news/scaffold/  throws an error of: Unable to load the requested file: view.php

uri of: site.com/index.php/news/news/scaffold/  just runs the ‘index’ function from the news class.

The Scaffolding of CI is very limited (it doesn’t even work with controllers in subdirectories). I’m not sure if it works with Matchbox, and I know of people who’ve had problems with it as well so its not just you 😉

However, if it is possible you are definately going to need to have a controller with the same name as the module, you can then access it by yoursite.com/module/method (no need for controllername). Try it out, I’m afraid it won’t work though.

I might extend the Scaffolding class in the next release in order to let it work with modules 😊

I was wondering if I have 4 modules using the same helpers, libraries, models and scripts. Does Matchbox allow me to just autoload all these once, and store them once or do I need to include them within each module folder and load them each time?

In lieu of scaffolding, you could create module with a view containing an iframe and set the iframe attributes to load something like phpMyAdmin which might prove more useful for your needs.

I appreciate the scaffolding info.  Just good to make sure I wasn’t barking up the wrong tree.

The scaffolding sounded pretty cool at first, but just having another phpMyAdmin window open is sufficient.

phpMyAdmin > Scaffolding 😊

Anyway, megabyte: yes, you can just autoload a resource and it’ll be available in your modules as well. You can even autoload resource from within modules and use them in the other ones as well.

I was wondering if I have 4 modules using the same helpers, libraries, models and scripts. Does Matchbox allow me to just autoload all these once, and store them once or do I need to include them within each module folder and load them each time?

Since four modules require the same code, you could use the standard CI directories for libraries, helpers, and models rather than duplicating the files in multiple module directories. CI will still find those files if autoloaded from autoload.php or if loaded from your controllers.

However, the less a module depends on external code dependencies, the more it is loosely coupled with its current application and the easier it is to install since there are less dependencies. This makes it easier to move a module to other applications for reuse.

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.

not working as expected..

when try to access http:/localhost/ci/index.php/auth/activate/user/activation_code

where auth is a Module having a controller activate, with user and activation_code as variables.

when i access http:/localhost/ci/index.php/auth/register or http:/localhost/ci/index.php/auth/login
all works fine.

can you figure out where am i loosing.

Well if your controller is /activate, then /user must be the method not a variable. That might be your problem 😊

esra: the module installer I am working on is in fact a module itself. And I think that if a modules only dependency is, say, a single library, then I believe it should be included within the module itself, however I am giving developers the opportunity to give their modules other module dependencies.

Well if your controller is /activate, then /user must be the method not a variable. That might be your problem 😊

yes i understand that but, i am having a default method index as a method to handel the variables and using the URI to have the other two filed .

secondly the error is “page not found”..

The index method is only called in two situations:
1) if there is no segment after the controllername
2) if the segment after the controllername is ‘index’

Even though you have an index method, CodeIgniter will still load the /user method. One thing you could do was to exchange all your controllers in the module with a single controller named the same as the module itself. Then you can access each method like you accessed the controllers before:

instead of
http://www.example.com/modulename/controller/method/variables

it is just
http://www.example.com/modulename/method/variables

It is described in the documentation on http://matchbox.googlecode.com/ as well.

esra: the module installer I am working on is in fact a module itself. And I think that if a modules only dependency is, say, a single library, then I believe it should be included within the module itself, however I am giving developers the opportunity to give their modules other module dependencies.

I think module dependancy should be resolved differently:
Let say i build a webservice and have a webservice libray.
Lets assume there’s “module1” and “module2” which both need the webservice lib “wslib”.
Why duplicate?

I see these options:
- wslib is installed as a core lib to ci
- wslib is provided by a module (that just includes only that lib)
- wslib is part of an entire module like module1.

In these cases module2 can:
- use wslib if installed to CI core directory.
- use wslib if it can use libs of another module. (which would create a dependancy to that module like mod_wslib
- use wslib if it can use libs of another module like module1(in fact similar to the above)

So to consolidate this there are infact just two options:
- wslib is installed as a core lib to ci
- wslib is provided by a module
In any way, there might be also a version check required. I would suggest something like the major / minor version scheme:
Increase in Majorversion: Module is still compatible to prev. minor version
Increase in Minorversion: Module is no longer comaptible to prev. major version.
This way, module2 can ensure module1/mod_wslib exists in an compatible version.

Now this means: The modules need to have an API to talk to the module manager (wether build as a module or not does not matter). But a sort of API will be necessary anyway to get the modules managed via the manager.

Regards

Wolfgang

Well, everything would be so much easier if everything was released as modules, since people would be able to provide version numbers for everything.

Regarding version increases, the way I’m doing it is also lettings people assing a variable that tells the manager what version the current version of the module is backwards compatible with. So when another module is dependant on ‘module1’ version 1.2, the module manager will make sure that the installed version of ‘module1’ is backwards compatible with version 1.2 or lower.