Thread

i think this idea of integrating a dependency checker is another instance of solving a problem that:

a) doesn’t exist yet
b) won’t be a big deal

just let module developers keep their modules up to date with the latest libraries. period. if the module changes the library changes.
the downside is clear and small: extra code to load.
the upside is huge: fewer variables to account for, less clutter in the module code, fewer hurdles for potential module developers.

imagine asking a module developer for help with a dependency setup like the one outlined above? talk about a nightmare…
imagine the documentation: now, build a version check function to account for the fact that someone else might have already installed the library you integrated.

that would turn me off completely from building modules.

kiss.

I’d like to know if others feel the same way. Please, let me know what you think people.

i think this idea of integrating a dependency checker is another instance of solving a problem that:

a) doesn’t exist yet
b) won’t be a big deal

just let module developers keep their modules up to date with the latest libraries. period. if the module changes the library changes.
the downside is clear and small: extra code to load.
the upside is huge: fewer variables to account for, less clutter in the module code, fewer hurdles for potential module developers.

imagine asking a module developer for help with a dependency setup like the one outlined above? talk about a nightmare…
imagine the documentation: now, build a version check function to account for the fact that someone else might have already installed the library you integrated.

that would turn me off completely from building modules.

kiss.

Keep in mind that the installer is a module. Thus, any developer can choose to use it or not use it depending on their needs. Also, it might be possible to build other implementations over time that handle the needs of more complex applications or suites of applications.

There was Modular Separation 1.x.x, then Modular Separation 2.x.x, and now Matchbox 0.x.x (there was also Dynacheck, Zawk, and Zacharias all of whom are the same person). Although dependency checking might not be a problem for you, I’m sure it is a problem for some of us who need to correlate module versions with versions of CI as well as the versions of external libraries. CI development is slow at the moment, but this is probably going to change in the future based on EE objectives and goals. Modules built for CI 1.5.x might not work when 1.6.x or 2.x.x is released. At this point, who knows what the future holds regarding CI development. I use an external javascript library called EXT where the API has changed significantly over the past year. Thus, I now have dozens of modules that no longer operate correctly with EXT 2.0 and were designed for Modular Separation 1.x.x or 2.x.x and most of them need to be rewritten to take better advantage of Matchbox improvements.

Versioning should be optional for those who need it. The installer could be version aware if a config option is set to TRUE.

Regarding module dependencies in general, Dependency Injection (Inversion of Control) might be another solution to experiment with later after a PHP5 strict version of CI is released. To do this, the front controller and module controllers probably need to be extended from the same abstract class or implemented from an interface, allowing a container solution like the Java PicoContainer to be used. There is a PHP port of PicoContainer. Then a module could request its dependencies rather than including or requiring them. Of course there are pros and cons—much better for unit testing but a bitch to debug problems related to external dependencies.

Generally, I think config file options with preset defaults are a good compromise for most of your arguments.

Generally, I think config file options with preset defaults are a good compromise for most of your arguments.

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.

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.

I really like the look of this, its exactly the sort of thing i have been attempting to use in our systems for years but never seen a good one, and now you are developing it on CI its great.

Id like to know a little more about the installation of the modules, i have seen some chatter on the post about an installer, is this something you are working on now…

Also do you think its possible to have a module so it includes admin functionality aswell, as this would mean that you can easily add to an application, one zip or install and you have the admin and front end functionality…

Yes I’m working on a module installer and yes you can have both front and back end functionality in one module 😊 Read the documentation on http://matchbox.googlecode.com/

This all seems really good, are you divulging an ETA on the installer?

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.

Keep in mind that we are talking about a module which you or myself might elect to use or not use. I look at Matchbox as an extension to a framework which was designed to be extended and Matchbox could be extended just as well. Using what Zacharias provides is totally optional. I do not have a problem with expanding upon whatever Zacharias chooses to release. It’s no big deal to me—that is, another installer module could be released.

Modules can have their own config files which are encapsulated within the module directory structure as well as their own routes file (assuming Zacharias incorporated the hack mentioned in the old thread). Installer module is obviously an Admin-only module and could include a user interface for viewing and setting config values.

swanweb: I do not dare to give an ETA on the installer, I won’t have much time untill sometime after christmas (at least not the amount of time I want to devote to my module installer). Ask me again after christmas 😉

esra: No I haven’t incorporated the routing-hack, could you perhaps provide a link to said post? 😊

routing hack would be extremely usefull, say, you’d want to have an admin interface with default which would be accessible under /admin url and it has to load the admin default admin view which would be stored under “default_view.php”

You wouldn’t need a routing hack for that. Just make an /admin subfolder in the modules controller directory.

well that is correct, however I cant specify default controller, e.g. when I point to site.com/admin/ there’s a 404 message (i have created modules->core->controllers->main which loads main view from modules->core->views->main) so basically i want to be able to specify that the default controller to call should be main…..

or I missed somethin ? 😊

edit: oh dear, i truly am a dumb f.ck, must be the joint i’ve smoked this mornin :D

how to load a model of a module in a controller.

/modules/user/controller/user.php
/modules/user/models/user_model.php

I tried
$this->load->model(‘user_model’,‘user’);

its giving error “can’t load class user_model’

Oh i am such a ...... my user_model.ph is empty..

sorry i got it working now

were to place an assets for a module and how to access its IMAGES , CSS and JS scripts ,

i have different modules with totally different asset file.
but if i put them inside a module folder i am unable to access it in a view (via a url)..

ex. -
/modules/user/controllers/ ...
/modules/user/assets/ ...
/modules/user/views/ ..

in view i am unable to access the urls ,
below is what i am trying , but its not working :
<link rel=“stylesheet” href=”<?=APPPATH?>modules/user/assets/css/style.css” />

plz suggest how to implement it..

How to print $_SESSION in a view..

A PHP Error was encountered

Severity: Notice

Message: Undefined variable: _SESSION

Filename: views/form.php

Line Number: 2

I am getting the above error when i try..