Modules

Yii 2.0 General Discussions
41

Modules need to stay (see below for my visualization of a package).

This should be in another thread, but some effort needs to be directed to Portlets both in the documentation, in the directory structure, and most likely in the framework code. Portlets are like the blocks used in Smarty or Postnuke (and the other Nukes) and should be treated as separate entities within the directory structure as are modules. It would be nice if Portlets could have their own conditional folder structure for storing related message files, views, and config information (definitions of portlet-related parameters used by the integrated widget) and more examples in the docs. Most of the users here do not know how extensive the advantages of using portlets can be as they work on more complicated applications. Any layout can include portlets. Portlets can be displayed in a layout conditionally when triggered by another portlet or widget, etc.

What would be nice is more of a formalized approach to issuing events and subscribing to events at the module level and application level (if modules are not used by an application). I prefer a Publish and Subscribe discussion in the docs versus an Observer and Observable discussion becuase it is more intuitive. There should be examples and discussions about using events for inter-module/inter-controller communication. It would be nice to demonstrate chaining events to perform a process encompassing the actions of several controllers.

What is really needed is a tutorial on how to transform and improve the Blog tutorial. For example, converting the blog into a single content module supporting several flavors of content (blog, articles, news, etc.). Refactoring the comment code as a standalone module or converting Contact into a module supporting multiple contacts, etc. Using portlets in the same tutorial to demonstrate their usefulness and advantages. Actually building a theme for an application to demonstrate the differences between a theme and layouts, etc. Their are holes in the sample application offering from a newbie point of view.

In my mind, a package could be:

  • Installation package consisting of a single module, portlet, widget, component, message file, etc.

  • A suite of related entities such a collection of modules, associated sub-modules, associated portlets, etc.

  • An upgrade package for Yii, the application, a module or anything else

  • A collection of images for application usage

  • A single file, such as a component, single file extension, message file, etc.

  • A package could include subpackages

In other words, any installable or upgradable item. For an example, see Joomla.

If this is where samdark in headed, I will climb in the same boat.

What is needed to make this work is an application level installer, most likely a module possibly with sub-modules or a good module configuration solution for tossing files where they belong (somewhat like an old USENET-like or Fidonet-like mail tosser; saying that makes me feel older). If samdark is also thinking about something similar, our minds must be on similar trajectories. For installer ideas, also look at Joomla.

@qiang… Joomla, Mambo, and a number of other open source projects get indirect help each summer from Google’s summer code development program. Its Google’s way of supporting computer science majors who need to earn tuition or extra money over the summer months. The Joomla team proposes several challenges based on code they may need in the future. Google exposes the ideas to computer science majors who make proposals about solving those problems or requirements. Joomla gets to select the students who will work on their summer coding projects by reviewing the proposals. In turn, Google provides a grant, funding the students summer coding project. Joomla is not obligated to use any of the ideas although they have many times in the past, usually after some refactoring. As I understand it, the act of participating in and meeting the challenge of the projects objectives and goals is sometimes a way of getting extra credits at some universities. You should investigate this program. Not sure if he is still in school, but a program like this might be interesting for someone like Jonah.

42

I see many people use modules there, but I have to admit I’m kind of disappointed in the Yii modules last time. There are several reasons:

[list=1]

[*]It is hard to keep modules self-contained. Example: User module and News module. They work fine independently, but what if I want to make a relation between UserModel and NewsModel? I have to modify both modules code including models, controllers, views (e.g. to show news author).

[*]It is hard to extend a module. Example: I want to extend some module’s components, add my actions to controllers, etc. Should I create a new module even if I need to add only 1 method to it’s model?

[*]It is hard to configure module components. It can be only done via *Module class, but I don’t think it’s a good idea to put everything inside the single class (including controllers’ configuration, some models’ attributes, etc.). Moreover, module’s models don’t know anything about their module, what means they should access module directly via Yii::app()->getModule(). Example: make table name configurable.

[]Usually modules internally rely on their application ids, e.g. to include components and models using 'moduleId.components.’, but really “reusable” modules shouldn’t do that.

[/list]

Some months ago I tried to implement “real” modules nesting and got some success, so when I wrote MyUserModule extends UserModule all controllers and views from the parent module worked fine inside child module and I could replace/extend any of them. But I didn’t solve the problem of extending models/widgets and making relations/dependencies between modules.

Now I don’t use modules. I prefer to keep some base models, action classes to work with these models + widgets. In every particular application I just build controllers and views using these components, like a lego :) Actually not everything is so perfect yet, but I’m working hardly in this direction.

Based on my post I would call a package “a set of models, actions and widgets, which can be used to rapidly build an application’s module” (even if it won’t be a real Yii module, but just a set of controllers and views).

Summary: modules are good for separating application logic, but not too good to keep using the same modules in different applications without modifying their source code what makes modules useless as stand-alone components.

P.S. It’s just my opinion based on my own experience. Any criticism is welcome, I’m always ready to change my point of view :)

43

I think that now module is a good concept to structure code, but it fails to be an application-inside-application standalone piece of code for following reasons:

[list=1]

[*] module can not be just installed into application - it should be enabled in the app config

[*] module has no own config - unlike application it should be configured in the module class (yes, I seen arguments in the tread above that all should be in the app config, see suggestion below)

[*] some configuration should should be done outside of module. Now such configuration is URL rules - it can not be defined inside module, because module is usually created on demand (when request is redirected to the module). Another example of such code can be registration of events to listen if we will have some global events handling (see discussion here).

[/list]

So my suggestions:

[list=1]

[*] make modules enabled by default (without need to do this in


'modules'=>()

section of the main config). And we can use a config to disable module:


'modules'=>array('unusedModule'=>array('enabled'=>false))

[*] add config file for module - the same way like we have for application. To allow configure module from the app config (or override config provided by the module) we can still use ‘modules’ section in main app config - it should be merged over the module config file.

[*] add a special method (static?) to module class like ‘register’ - it will be invoked for all modules and should perform ‘light’ initialization, for example, add URL rules or subscribe to some events / declare own events (maybe instead of static method the application can directly read this data from the module config?). And when request is redirected to the module or we use Yii::app()->getModule() then ‘heavy’ initialization is performed - module object is created and ‘init’ method invoked (the same process as it is now).

[/list]

As for extending modules problem (see previous post by andy_s) - I think that inheritance is OK. If I have two generic News and Users modules and need to add some relations between modules then I can disable original modules, add two new modules and inherit controllers / models from generic modules. I used this approach and may say that it is good and allows to reuse most of code from original modules.

44

I see it this way too.

A ‘Package’ is a set of models, controllers, views, and maybe extensions.

And installing a ‘Package’ means, extracting/putting each of these ‘parts’ to where they belong, e.g.

putting the controllers into the ‘protected/controllers/’ folder,

putting the models into ‘protected/models/’ folder

etc.

Since not everyone has the same folder structure, the ‘installatin script’ could ask for the path for each of these ‘parts’.

Once the package is installed, it is (or can be) interwoven with the rest of the application.

This is not possible with the Yii modules as they are now (if I’m not mistaken), because of the issues below.

I agree with all the points above.

The lack of communication between modules reduces flexibility.

Could the modules not be implemented in a way, that makes it possible to reach their controllers, views, models, etc. from everywhere? So that for example a view of a module can be partially rendered within another module, or the methods in a module-model can be used within another module…

45

Package is, indeed, a matter of code distribution, and, it can be of different types: module, component, widget, theme, etc. I think that a simple naming convention will be enough to know where will be it’s place (or the path inside of protected folder should be provided).

Module is a subapplication, an application under another application. I think it has to stay, also, I think that it has to be improved and the most ideas about that are already written.

46

Hmm, outsider view :)

Sounds like the issue here goes back to a problem with the base architecture. What I mean is that the base architecture defines what is sitting on top: module, widget, package, portlet, extension, component … Lol, I’m lost because some of these things sound like the same thing.

I like the symfony component idea. But will support anything that is defined in the core that will allow an easy way to drop in a module and have the system register it.

Maybe a single package is not the right way to go but rather an installer that lets you install a lib in a library folder that allows other components to use it too.

Crap! I’m using terms as being interchangeable :(

Sorry for mixing topics, but like I said, this does sound like a vague definition issue rather than a functional issue!

Note: I’m a huge fan of hooks/plugins :)

47

Maybe a good thing is to start defining the words, a dictionary of terms. As ex:

module: a set of MVC that can act as an application inside the framework

widget: a complex web element that can reside only inside a page

portlet: in the end is same as widget

extension: to be defined, maybe a set of functional components, for the moment could be anything from the others, maybe can disappear, or maybe only for extending the framework with other frameworks as Zend.

component: a class that extends or adds new functionality to the framework

package: a something that can contain one or many of the above (maybe other things if the dictionary grows. assets? behaviors?) and helps for installation

I’m not so good in definitions but I think is a good idea to define first the things that are allowed in the framework, what is their role and description.

Longer we have ambiguities, longer the talk.

Best

48

What would be the difference between an app and a package?

The "word" extensions sounds like it should be extending the core.

Definitely agree about agreeing upon a set of terms :)

49

an app is what you are creating with yiic webapp

a package could be a zip file (kind of what is it right now in extensions directory) or something else (see other topics)

50

Thanks!

But having to research other topics is what I’m trying to get at. Terminology should be dead simple and easy to pick up.

Ajax is way easier to comprehend than asynchronous synchronized swimmg what-ever sexual males! :) joking

51

Paul Apostol

Good idea.

52

@SapporoGuy

There is a link for a topic on packages few posts up

The terminology is not always simple, very often are misunderstandings between the container and it’s content. AJAX is a label with a big definition in it’s back and all of us knows or have an idea about what is it (my mother use it for washing dishes :rolleyes: and is not a joke, that’s the name of the brand). That’s why I’ve proposed to have a term dictionary.

@samdark

THX

And because we are in “Module” topic and we are talking about PHP 5.3 (mainly namespacing) I think that most of the folders in protected should disappear. We can talk here about taking examples from Django or Java or whatever the best example we can find. I don’t have an idea how the package versioning could be made but in terms of architecture my point is to have as many packages with minimum functionality. Even for assets. That way jQuery/UI, Bootstrap (my favorite right now), MooTools could be an option for each of us.

As ex. the structure could be (and the Rights module as I’m working with it right now):

protected

-components = components that should be customized for each application (now are UserIdentity and Controler).

-modules (packages) = where the content of the packages should go

–crisu83 = vendor name

—yii-rights = project name

----RightsModule = module class with namespacing crisu83\yii-rights

----models = folder

-----AssignementForm = a model with namespace crisu83\yii-rights\models

and so on

We can talk also about a package that will contain a simple class that implements a behavior:

vendor\project\behavior\class

This time I’ve used “project” instead “package” or “module” to be compliant with Composer/Packagist naming convention.

Dot notation is a good thing also because of aliasing and should be kept, but we will have, also, the namespaces for autoloading a class (namespace aliasing? instead of crisu83\yii-rights\models could be YRM).

And again the difference between the module and package narrows. But I’m saying again that they are just labels for the archive/container file (package) and it’s content (module)

Other ideas (maybe are already told):

  • all the namespaces could be prefixed with yii

  • package version conflict validation

  • possibility to keep module content outside web app

  • yiic webapp with an extra parameter that tells the name of the default module being developed (otherwise Default)

  • themes delivered as packages

  • a set of packages/modules installed by default for the base application (or just connected from an external folder as gii is today)

In conclusion, I’m voting for modules and against web application made in protected folder (models, controllers, views folders).

Best

53

@ Paul A

Haha, I actually know that Ajax! Pretty sure that was the beefy guy showing off his biceps! No, not the green giant or arm and hammer!

I’m all in support of consolidating names and terminology! It provides unity and saves time!

The way you decide what is what is not as big a concern as long the terms and associations are intuitive :)