Posted 05 August 2011 - 09:01 AM
- 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.
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?
Posted 05 August 2011 - 09:15 AM
And a module is also an extension, at least there are some in the extension repo.
Posted 05 August 2011 - 09:29 AM
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.
Posted 05 August 2011 - 09:38 AM
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.
Posted 05 August 2011 - 10:16 AM
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?
Posted 12 August 2011 - 07:56 AM
- 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.
Posted 03 September 2011 - 09:07 AM
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.
Posted 13 September 2011 - 12:39 PM
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();
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:
Posted 22 September 2011 - 03:27 AM
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".
Posted 22 September 2011 - 02:01 PM
I tried to implement such an global registry as "proof-of-concept". See http://www.yiiframew...c/21901-events/
Posted 22 September 2011 - 08:34 PM
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.
Posted 06 October 2011 - 08:26 AM
I like that idea.
Posted 14 October 2011 - 08:34 PM
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.
Posted 19 October 2011 - 03:19 PM
Posted 05 November 2011 - 01:58 AM
Modules are best for organizing functionality.
Posted 07 November 2011 - 09:19 AM
It's an art school that have many branches. Each branch have it's own subsite, for example:
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:
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.
Posted 04 January 2012 - 06:36 AM
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