[El Forum]

[eluser]zdknudsen[/eluser]
Discussions has been moved the to Wiki discussion thread.

[El Forum]

[eluser]Majd Taby[/eluser]
"Matchbox is a set of extended libraries for CodeIgniter"
Does that mean you can bundle this with a CI installation just by adding the libraries? i.e. no core manipulation.

[El Forum]

[eluser]zdknudsen[/eluser]
Exactly.

[El Forum]

[eluser]esra[/eluser]
If Module Manager was released as a module, it could be considered optional and an independent download.

[El Forum]

[eluser]zdknudsen[/eluser]
Yes, that would seem the most logical solution. However, that would mean users would have to not only distinguish module and standard CI contributions, but also modules with and without requirement for the module manager. But that might not be that big a deal...

[El Forum]

[eluser]gerben[/eluser]
Congratulations Zacharias! A great tool now also has a great name

Do you guys feel a Module Manager is a worthy addition, and if so, what features would you like to see implemented?

It would be handy to have at least an example on how to build such a module-manager. And if you were to take it to extremes it would of course be great if the module-manager would contain zip-upload, so users can easily add modules through a web-based admin panel. But I don't know if you were thinking along those lines.

A question though: I read that in Matchbox 0.9 modules can be placed in application/ or system/, but would it also be possible to place the modules-folder in the BASE_PATH of CI? So the same place where the main index.php resides? Or would I have to hack into Matchbox to achieve that?

[El Forum]

[eluser]zdknudsen[/eluser]
Thanks, I fond of the name as well ^^

A full-fledged module manager with downloadable modules have crossed my mind, yes. What do others think?

Regarding the BASE_PATH, the BASE_PATH is in fact your /system folder. But if you wish to place it where your index.php reside I would like to ask: why?

[El Forum]

[eluser]gerben[/eluser]

Regarding the BASE_PATH, the BASE_PATH is in fact your /system folder.

Sorry, I meant base_url.

But if you wish to place it where your index.php reside I would like to ask: why?

I thought you'd never ask The reason for this is that I develop open-source software, and I want to make the software as easy to use as possible for non-technical people. This is also reflected in the directory-structure: everything that should be easily accessible to users, is in a seperate folder called /user-content/: layout themes, widgets, config, etc. Another benefit of this approach is that users can upgrade to the latest version of my app, without overwriting any changes they made to their themes, config files, etc.

I've also created an architecture for widgets, which are basically mini-CRUD "modules", which can be dragged around and placed anywhere in the layout. I don't have a zip-installer for widgets, so I thought it would be easy to also place the widgets-folder inside that user-content folder for easy-accessibility.

Anyway, a zip-uploader for modules would solve this "issue" in an even user-friendlier way, so I opt for that one!

[El Forum]

[eluser]zdknudsen[/eluser]
Well if it is just for user-friendlynes I think I'd rather go with the module manger. The resource locater already looks in quite a few places. However, I'd still like to hear peoples thought on what features one such manager should include.

(I'll still have a look at how one might go on about having it look at the base url )

EDIT: One thing you should note about having modules in the base url (root) or any other place than in the APPPATH. Controllers won't work. So if you want to use modules with controllers (which I assume you do) you have to have them in your application folder. However, modules just containing helpers, libraries, etc. can go in BASEPATH.

[El Forum]

[eluser]xwero[/eluser]
Great stuff, I really like the direction you are going with it.

What would be the scope of the module manager would it handle set up/removing module related database tables. As for the interface it would have some form of authentication procedure i guess so will it be build in or would it be up to the developer to implement it?