Matchbox RC2

[eluser]zdknudsen[/eluser]
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.

[eluser]esra[/eluser]
[quote author="megabyte" date="1196909966"]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?[/quote]

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.

[eluser]esra[/eluser]
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.

[eluser]medium_kreation[/eluser]
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.

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

[eluser]zdknudsen[/eluser]
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.

[eluser]medium_kreation[/eluser]
[quote author="Zacharias Knudsen" date="1196969024"]Well if your controller is /activate, then /user must be the method not a variable. That might be your problem [/quote]

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"..

[eluser]zdknudsen[/eluser]
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
www.example.com/modulename/controller/method/variables

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

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

[eluser]WolfgangA[/eluser]
[quote author="Zacharias Knudsen" date="1196969141"]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.[/quote]

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

[eluser]zdknudsen[/eluser]
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.