Modules

Yii 2.0 General Discussions
21

I think modules should be independent of packages.and packages can be either module depend or universal based on installation and usage.

cheers

22

Absolutely agree. I think that modules are actually quite powerful currently and I would hate to lose the capabilities that they provide for resuable code between common sites on a server, which is still very coupled to the application that it’s created for. I don’t fully understand the new package concept, but it seems like that is more disengaged/abstracted?

23

As said in another thread: A package is just a standardized extension format.

And a module is also an extension, at least there are some in the extension repo.

24

My concern is that we not go the route of making modules so completely ‘self contained’ that they’re not able to integrate into a core application properly. Yes, sometimes I want to be able to just drop a blog into my application and have it work without needing to integrate, but when I drop an admin module into my application, it needs to be MUCH more tightly interwoven.

Because of this, I would definitely argue that they need to be distinct and remain distinct. Yes, you should be able to package modules, but not all modules should be packaged.

25

Yes, I mentioned that also. Modules often need i.e. to set application configuration params.

And maybe they have also to setup a database and a folder in file system.

I agree, they must not be packages, but they should have this option.

26

Only to make this more concrete…

Modules consist of different resources, but are distributed as one whole, without publishing its internals to the rest of the application?

So the usage of a installed module is like now:

  • through its web interface (including possibly web services)

  • in code by “Yii::app()->getModule(‘myModule’)->useItsApi();”

A "packages" is also something that consists of different resources and can be distributed, but upon installation, it somehow "extracts" or "installs" those resources? So after distibution/ installation of the package, its the packaged resources that are of interest instead of the "package" itself as opposed to "modules"?

So the usage of something installed with a package would depend of what it actually is.

Module installed as part of a package:

  • through its web interface (including possibly a web service)

  • in code by “Yii::app()->getModule(‘myModule’)->useItsApi();”

Behavior installed as part of a package - in config:




'behaviors' => array(

  'possibly' => 'application.behaviors.BehaviorName',

  'orMaybe' => 'application.behaviors.packageName.BehaviorName',

  'orEven' => 'application.packages.packageName.behaviors.BehaviorName',

)

Behavior installed as part of a package - in code:




$component->attachBehavior( 'possibly', 'application.behaviors.BehaviorName' );

$component->attachBehavior( 'orMaybe', 'application.behaviors.packageName.BehaviorName' );

$component->attachBehavior( 'orEven', 'application.packages.packageName.behaviors.BehaviorName' );

Widget installed as part of a package - in view:




$this->beginWidget('application.behaviors.BehaviorName');

  ...body content that may be captured by the widget...

$this->endWidget();


// alternative layouts. However way a package might extract its contents.

Model installed as part of a package - in controller:




$model = new PackageNamespace\ProvidedModel();

$model->doSometing();


$this->render( 'view', array(

  'providedModel' => $model,

));

Is this the way you think of modules and packages?

27

In order to keep things easy to understand and easy to implement, I would propose a Package is a folder (or archive) consisting of the following:

  • collections of classes in a namespace equivalent to the name of the package

  • other dependencies, e.g. files that are not classes (images, css, js, views, etc.)

  • a package metadata file of some sort

The latter file is what makes it a package - this file could be a class, plain text, INI, XML or HTML file, the format is not the most important thing.

It defines practical information, such as the version number and release-date of the package, what version of the framework it was built for, supported languages, a list of dependent packages (optionally with version number) in a machine-readable format so package managers can use the information. It might define optional supported packages too - packages that are supported but not required.

It also might contain human-readable information, e.g. author name, contact info, package descriptions in various languages, etc.

Your classes and dependencies should follow common Yii conventions - they should work independently of the package file itself… I think this is one of the most important points - the module, behaviors or whatever library it is you’re distributing, should be all-conventional Yii components, working independently of the package file. Your package should not depend on the package metadata-file, and your metadata-file should not depend on anything in the package - what makes it a package, is merely the fact that you provided package information for package management, followed certain conventions (mainly Yii conventions and package namespace convention) and decided to include the package metadata-file in your distribution.

28

What I want to see for modules is module migration support.

Since this is already implemented here, may I suggest that it be merged into Yii?

In my own apps I rely on migrations, and it would be really nice if the modules I am using could be migrated just like the rest of my app.

Otherwise I have to modify the modules and add migrations ‘manually’ - which is both tedious and error-prone.

29

It should be possible to reference module component id’s instead of only application component id’s (example: cacheID). This can be done like $cacheID = ‘moduleName.cache’. While qiang mentioned once (and I agreed) this may be troublesome with deeply nested modules, I simply see no better solution at this time. In the end Yii is no CMS were everything can be dropped in to work perfect. For 3rd party modules it might be troublesome, but complex projects were developer has full control over everything will benefit.

Maybe we could find a way to make modules even more powerful while preserving the simple configuration of Yii. At least it would be nice to route requests to a module url manager. This could be done by an “internal” url rule in the main url manager that may pass a request to a module url manager in case a certain scenario matches (eg hostname). It’s just a thought though. Don’t ask me about exact implementation details for now. All I know is url management is a struggle in Yii when working with complex projects. Simple example:


http://www.example.com/ <- main application

http://admin.example.com/ <- admin module

How to create url in admin module for main application (of course without using rules including hostinfo)? This doesn’t work of course:


'' => 'site/index',

'' => 'admin/site/index',

This is how it may be done when each “section” of an application has it’s own url manager:


Yii::app()->urlManager->createUrl();


or short:


Yii::app()->createUrl();

and vice-versa:


Yii::app()->getModule('admin')->urlManager->createUrl();


or short:


Yii::app()->getModule('admin')->createUrl();

Though within the main application or within a modules controller, this would still work and lead to the correct url manager:


$this->createUrl();
30

I don’t agree. One of the great things about Yii is the speed of it. I would feel bad using modules, if I knew, each module would slow down my application. The config is the place to combine (and configure) every piece of an application.

What I miss in modules:

  • Some kind of global events registration.

If I developed an activity feed module, I should be able to configure (in my config) which events it listens to. In my “User” model I would fire a “newUser” event, and then some handler function will be called in my activity feed module. I’m not really sure how this should be designed, I assume some php array would fit. What it can’t be, is some expensive call to a class to register each “event listener”.

31

With the current design, this will always be sort of “expensive”. It is, because listening module won’t be existent at the time the event is fired. So all the listening modules need to be created and initialized first.

I tried to implement such an global registry as "proof-of-concept". See http://www.yiiframework.com/forum/index.php?/topic/21901-events/

32

I am not sure if I like the direction you are taking, guys.

Remember one thing: We like Yii because it is simple, elegant and fast.

We also like programming.

And programmers tend to like being clever.

There’s really no end to what we can cook up, but there’s also a real world out there.

I trust the Yii team to be able to balance everything.

I prefer a finely balanced Chefs knife over a Swiss army knife.

33

Application should only consist of modules and “Default module” which is set as.(symphony’s way)

34

I like that idea.

35

One thing I have seen from other people using the modular approach is that all their configuration goes on the main config.php file. In my projects, I never had the chance to work on reusable applications (i understand modules as sub-applications that plug into any main application) but I have seen a lot of other works that asked me for consultancy and the configuration of shared objects that modules rely on end up to be on the configuration file as dozens of alias importing paths that at the end tend to slow the application.

If that is the only way, it could be good that the modules configuration could be set ‘on the fly’. I mean, load the configuration files as required so there is no need for the main config.php file to be overloaded until the module is requested. Again, I do not use much modules, in the analysis of my applications structure there is nothing i could not solve by using shared common folder or changing main application structure (frontend, common, backend). But could be great to load and cache on module request -do not know if i explain my self properly.

36

IMO, if a module itself contains some code settings, such as db settings, then it can be called packege.

37

As a cross-reference: Yii 2.0 Module configuration

38

Module approach is good one. It should be continued. I mostly group my site functions into groups such as blog, admin, photos and common section of codes into component such as vote, comments etc.

Modules are best for organizing functionality.

39

Adding to the module discussion, I used modules in another context: to share common code. For example, in this site I made (sorry brazilian portuguese only, but I’ll explain the concepts):

http://www.abra.com.br/

It’s an art school that have many branches. Each branch have it’s own subsite, for example:

http://www.abra.com.br/brooklin

http://www.abra.com.br/alphaville

All branch sites are equals, but each of course have different data.

To do this, I created a single "BranchModule", and registered it multiple times with different ids:

‘modules’=>array(

'brooklin'=&gt;array(


     'class'=&gt;'application.modules.branch.BranchModule',


     ...


),


'alphaville'=&gt;array(


     'class'=&gt;'application.modules.branch.BranchModule',


     ...


),

)

using the module ID as a key to the databases and custom images directories. This worked pretty well, to add a new branch I just register a new module and add a record on the database.

40

Modules are fine IMHO. Please keep them.

They solve the task of encapsulating, say, user management, or admin, in a mini-app. They’re also easy to reuse by copy-paste into another app and altering the config/main.php

As for the config, it should go all into main.php. (Single Point of Truth: all config goes into one file)

You can very well specify module params in the main.php.

I’ve used and created modules, they are fine and portable(as long as you enclose all dependencies, like widgets and components, into the module)

+1 for modules