Questions related to module development

Hello All,

Please note that I’m posting here and not on the extension forum because this doesn’t concern a specific extension and I want to reach as many Yii developers and possible with these questions.

I’ve been developing extensions for Yii for the past year and a half and during that time I’ve encountered a few questions. Here are some for starters:

1. Module dependencies

If I would be to develop a smaller extension that I want to use in all of my modules would it be better to just build in the functionality instead of providing the extension and an extension within the module. Providing the extension with the module could easily lead to duplicate of code and naming collisions (assuming that PHP 5.3 is not available). What would be the best practice in this case?

2. Module themes

When developing a module that could be used in any Yii project there are some limitations to the user interface and lately I have been creating alternative UIs for my newest modules using Twitter’s amazing Bootstrap library. Now my question is how I should distribute the alternative views/css for my modules? Should I add a themes/bootstrap folder and place the files there or what is the best practice?

3. Modules with application components

Sometimes it’s necessary to both have a module and an application component for accessing the module functionality also outside of the module. Is it appropriate to include an application component with my modules and if so, should the configuration be split up between the component and the module? Have anyone else encountered a similar situation?

If you have any thoughts regarding any of the above questions please leave a reply below.

Thanks for reading.

Haven’t anyone stumbled on the same questions I posted above? It would be great to see other opinions on these matters.

This is an excellent idea, broaden my topic, I can not add my comment because I just learned yii

Surely someone has encountered the same questions. If you have or have an idea how to tackle one or multiple of my issues please post below.

If you really use it in several modules, extract it. Maybe don’t provide every small extension as a separate package, but provide one base library that contains all of your smaller extensions. So each module can specify as dependency: “baseLib >= v1.0.0”, “baseLib >= v1.1.0”, … Doesn’t introduce too many dependencies.

Didn’t ever work with alternative themes, but I think providing a module with one “default” style (css) that can be disabled if someone wants to do his own styling should be a good start. About alternative views… Really no experience. But I think it will only result in increased maintenance work. And whoever cares about alternative views will probably also care about a consistent look and behavior of all components across his application -> he will probably have to write his own views.

I don’t see the need of a wrapping component. I think a module should simply specify its API that can be used. Where’s the benefit of “Yii::app()->getComponent(‘foo’)->bar()” over “Yii::app()->getModule(‘foo’)->bar()”?

The module isn’t loaded unless the route points to that module. Sure it’s possible to always import the module but I don’t think that’s the right solution. So it feels like an application component is the correct solution for this…

A module will be lazy-loaded the same way as a component. The first time you call:




Yii::app()->getComponent('foo');  // lazy-loads component named foo

Yii::app()->getModule('foo');     // lazy-loads module named foo



It’s only that you can access components like properties:




Yii::app()->foo;



Which you can’t do with modules.

Yeah that’s what I meant by “importing” but I don’t still think it’s appropriate to load a module unless you’re routing to it. Also if you nest the module then the following won’t work:




Yii::app()->getModule('foo');



I think it’s perfectly clean to access the module using getModule(). After all, if you want to use functionality provided by a module, it needs to be initialized/ imported even if not using one of its controller routes.

For example, a userManagement module could provide an API to create/ delete/ activate users, to expose the same functionality as provided by a controller to other programmers.

If using a component, how would you access the module functionality from that?

Hi chris,

Before PHP 5.3 you’d have to prefix your classes, but I would like to abandon that.

Regarding dependencies, please take a look at this posting. I think we need a tool like composer for that.

Because I have extensions shared across core modules I created my own extension package p3extensions, like yiiext. This one is required by my Phundament 3 modules. I found this the better solution over providing extensions with the modules, for the reasons you said above.

I think providing a themes folder is one of the best options, some modules let you specify a layout or css classes, but this is limited. On the other hand you have to move the files manually into the themes folder.

Usually one is developing his application without a theme, maybe you stick to blueprint or bootstrap, but themes are mainly used to overwrite the default application files.

For improving this situation it would be better if Yii comes with a default theme enabled by default and with an improved directory structure for themeing.

IMHO your theme files are ‘buried’ within the theme directory, which is not user friendly and complicates their management.

Maybe (backend-)modules simply should come with their layout and views and you customize them with a theme if you need to.

But That’s more a discussion about module conventions. As there are no conventions regarding the points you mentioned. It’s up to us to define them :)

So you mean an image resizing app-component which is accessed by a media manager module for example?

If yes … I think that is OK, regarding the config I would say, that this is also a weak point of Yii, so there should be another convention for it.

Best regards,

schmunk

Related thread: UI components standardization