Advanced Module

EcotypeS

More from your "pest" on the other side of the globe. BTW -- I'm not really trying to be a pest, just trying to implement a rather significant application with less-than-optimal expertise. So, I depend on documentation and examples...and I'm grateful for the assistance I've received.

I think I've done all the easy stuff -- actually using Fuel as a cms plus many simple modules. The ease of creating these is one of the things that led me to Fuel.

I'm working on 3 things that are non-simple and definitely not off-the-shelf...and you will likely continue to get requests for clarification and assistance ...I put them off until I could not avoid them! All 3 look like Advanced Modules to me.

Simple Example(s) Are Needed for Advanced Modules

I'd like to suggest that you take the same example that you use to demonstrate the power of simple modules and create that as an advanced module...

I'm suffering from too simple (

backup

), not-very-relevant (

user guide

), or too complex (

blog

). It takes hours tracing classes and their parents to determine what would be obvious from a simple example. I'm on day 4 of what I could have just done as a CI / Fuel controller hybrid in about a day -- and I'm guessing I have at least twice as many more days to go.

Missing from the documentation are concepts that don't seem to be ignorable, such as function _remap() which isn't mentioned in the documentation and which don't have consistent examples in the available modules. I had to read Fuel controller code just to learn of the existence of such a function (I was getting 404 error whenever I had extra URL segments even though the routes seem to be good), and I seem to be using that _remap() function to take apart the URL and grab anything useful out of it totally manually -- I am accomplishing this, but the time to even learn about the existence of _remap() was an exercise in frustration ... and I'm still wresting with "there must be a better way".

Missing from the documentation is how to add javascript to dashboard views (I decided to just manually add them, the ones I need aren't picky about where/when they load).

Another concept for you: when you have nothing better to do, consider changing the documentation to allow user comments -- much the way the php documentation does. I think this would help get some examples and good practices out there.

You have a very good program here. I'm (usually) enjoying working with it. And I'm very grateful for rapidity of response that you are providing to user questions.

Thanks. Many thanks to "Admin" and "Lance"

Hope your Christmas is happy and wonderful.

Shirley

admin

Thanks for the comments. We are looking at ways to improve the documentation and will consider all your suggestions.

With regards to the _remap controller method, that is native to CI and would recommend checking out this page:
http://codeigniter.com/user_guide/general/controllers.html

Lance

With regards to _remap and being manual. It is. You're basically biffing all and any segments into one "pool" and then have to sift through it to find what you want.

I generally use this to spit out to other private methods in the controller.

An example is: http://buller.redgemmedia.co.nz/gallery

The gallery there is an advanced module. Everything from the pagination, archives, viewing and searching is done in one controller file using a _remap. Works very similar to the blog.


Something else that's not documented but is plainly obvious (once you know) is that if you're advanced modules are using things like linked_fields in the models and your Fuel controllers are custom, you're going to need to add in:

$this->js_controller_params['linked_fields'] = $this->model->linked_fields;

Otherwise the linked functionality isn't going to happen.


I also found that if you want your modules config file included, you have to explicitly set it in the < adv_module >_fuel_modules file with

'configuration' => array('module' => 'conf_file_name')

Don't think that's documented.

A good place to look for this kind of stuff is /fuel/modules/fuel/controllers/module. That sets most of the module stuff up with defaults that you don't set being set in: /fuel/modules/fuel/libraries/fuel_modules

If you look in fuel_modules::info() you'll see the default val for 'configuration' is an empty string.

I just found this out about the 'js_controller_path' 5 minutes ago too... The docs say if you leave it blank but set the 'js_controller' to your controller, the path will be set to your modules assets directory. In my case, this isn't so. I suspect this is when you provide it an array, not a string.

In any case, setting 'js_controller_path' manually with "/fuel/modules/< module >/assets/js/" works but only if your actual directory structures match that of the Fuel module, IE:

"/fuel/modules/< module >/assets/js/fuel/controller/YourController.js"

The fuel/controller bit on the end is needed. Again, makes sense once you know it..