Modules

Do you have any major feature requests for the module feature? Or do you think the module feature is vague/poorly implemented and should be dropped in 2.0?

In the other post (http://www.yiiframew...e-and-packages/), Samdark introduced package concept. What is the relationship between module and package? I think we need to make this crystal clear. Otherwise, developers would be as confused as us.

Do you have any major feature requests for the module feature? Or do you think the module feature is vague/poorly implemented and should be dropped in 2.0?

In the other post (http://www.yiiframew...e-and-packages/), Samdark introduced package concept. What is the relationship between module and package? I think we need to make this crystal clear. Otherwise, developers would be as confused as us.

A package could well include a module? I don't think one renders the other obsolete.

That said, I have never written or used a module - application components seem to be a better fit for most of my needs.

I have been working on some ideas for a publisher/subscriber-driven modular architecture for years now, but I think that's probably going to be a massive project on it's own - and again, this would be more than a module, so probably the package concept would be a better fit for that, too...

Don't drop the support for modules.
From my point of view, i want to be able to "install/uninstall" modules when i need to and i don't like that i have to define them in the config file, why should i do that ? a module is a self contained app so i don't want to be tide up by a config file, makes sense ?

Another thing that i don't like in the current implementation is the "default" controller of a module.
The "default" controller needs to have the name of the module, not be named default.

->Look for /modules/forum/modules/index/indexController.php
-->If found, check if it has actionIndex() method, if it does, run it, else search deeper
--->If not found look for /modules/forum/IndexController.php
----->If it is found then look for the actionIndex() method and if found, run it, else search deeper;
----->If not found go and look for /modules/forum/ForumController.php (default controller)
-------->If found then look for actionIndex() inside it and if found, run it else, run missingAction();
-------->If not found throw a 404.

I'm still a bit curious about the current construct of modules (see How to think of modules). Maybe I'm one of those abusing them. Or at least searching for something they don't provide.

When I thought about how to bundle the signals-module, it was basically: "Its some behaviors, some components, a webservice, maybe some views... lets see: a module is a self-contained software unit that consists of models, views, controllers and other supporting components. Perfect, it's a module!" But it's not... The components it ships are meant to be used by an application (at least some of them). It's not a standalone app within some other app.

And even if I think of modules that implement a forum, or a wiki... I wouldn't be satisfied by dropping it in and having that feature on my website. I liked to integrate them deeper, liked to use their models (statistics about users, posts, whatever), maybe their actions and controllers. I even liked the modules themselves to communicate with each other. Fire events here, react to them there.

It would be great if we could standardize on packages though, and I think modules should be distributed in packages - in many cases, modules will come with some additional feature, like a component or widget, that helps integrate the module into your application, so it makes sense to package them together.

The only instance I used a module was whenever I needed to create an "admin" or "members" section on a website.

But there were always problems with this and it was not very straightforward, especially when creating login systems for these modules. Some configs have to be entered in both main.php and AdminModule.php and they would usually conflict. Often have to use hacks to make it work properly!

So what I would like to request is to provide a "recommended" way of creating admin or member sections that can be kept separate from the main website.

A module may mature into the state of a package (without rework of the classes) but it should not be dropped. For example some modules i have written require access to my custom CApplication object. So obviously these modules would never be distributed so why should I be required to write extra code to make it a package ? I am also thinking that a module would likely be less overhead to load then a package - unless a package is "installed"..

Or do you think the module feature is vague/poorly implemented and should be dropped in 2.0?

Modules may not be really useful for websites but are absolute must when developing and deploying a larger, browser-based application that should be deployed on several different hosts by different users. Users may want to disable unnecessary features (modules) or, if it's a commercial app, they may want to purchase modules individually as needed.

Modules is not the same as packages. !
A module can be part of a package (maybe the only part) but it's not a package.

A module - in my view - is an application within the application.
You can - and should - develop a module as a full-blown app.
And then, when done, change it slightly to become an instance of a module instead of a webapplication.
Forum and wiki is good examples of modules.
In my mind.
Modules consists of - unlike components and widgets and other extensions - models, views, controllers, components, ... structured like an application, but living inside one.
That's a really useful feat.

Please don't drop module support, the concept is fine.
I used modules for almost everything, they do not have much overhead and they are very useful for custom frontends and are very reuseable.
For me it's like, if your component needs a database and you want to reuse it, you'll end up in a module.

I would rather like to see an update for the module configuration and installation.
Many modules need to set global application variables and there should be at least a convention for it.

Module concept can be possibly merged with package concept. Currently each module should have main module class extending CWebModule. Inside there are typically imports, default controller, default layout, etc. All this looks like it can be configured via package config. If there are controllers in class map, it can be used as an application, if not — it's just a component provider like current extensions.

That's really a great idea, Samdark!
If module functionality became a feature of package - like the way you said it - it would do away with the confusion as to what a module is, and isn't.
And everything would have the same "interface" for installation/activation/management.
Splendid.

I'm not sure how to merge the concept of module into package. IMO, they're different, according to our discussions here:

Package is about redistributing code. Conceptually it is close to extension as we call it in Yii 1.x. As a result, a package needs dependency information, and possibly some installation information. These are only used when installing a package. If some code do not need to be redistributed, they may not need to be packaged.

Module is about organizing code. As a whole, it is configurable for runtime use. A Yii module differs from other software units (such as widgets) in that it is accessible by end users. A module, if needs to be redistributed, can be made into a package.

I'm not sure how to merge the concept of module into package. IMO, they're different, according to our discussions here:

Package is about redistributing code. Conceptually it is close to extension as we call it in Yii 1.x. As a result, a package needs dependency information, and possibly some installation information. These are only used when installing a package. If some code do not need to be redistributed, they may not need to be packaged.

Module is about organizing code. As a whole, it is configurable for runtime use. A Yii module differs from other software units (such as widgets) in that it is accessible by end users. A module, if needs to be redistributed, can be made into a package.