Move user-related stuff to module advanced app

[dynasource]

I have seen an enormous effort to enhance the advanced application to make it ready for public. Part of this focus is to create a product that reduces the amount of questions and to kickstart new users as fast a possible (please correct me if I'm wrong).

Another advantage of the advanced app is that people can adopt a project standard which they can use to develop projects that are consistent and logically built up. There are examples for configuration of backend/frontend, examples for tests etc. etc.

With respect to these 2 advantages, I think it would be logical to include a setup of a module. Most people out here use Modules to structure their Apps. @samdark has given some sort of direction over here https://github.com/yiisoft/yii2/issues/1520 but I think this topic deserves more attention.

Yii is developed to be the most flexible and modular. A convention on the structuring of Modules seem very logical to me. Especially in the Advanced application, the absence of a module example is like giving a child Lego without its manual.

To come back on my first sentences. Why not enhancing the advanced app with a module example that fits the advanced app structure.

Opinions about moving user-related stuff into module, added by @samdark

Do it

• @dynasource
• @psihius

  Don't do it

• @samdark
• @tadaszelvys
• @klimov-paul
• @nineinchnick

[qiangxue]

I'm against doing this. There are just too many dependencies between the user module and the rest of the application. This is not a good example of using module.

[schmunk42]

@qiangxue Which dependencies has the User module to the rest of the application? I can only see Session::Flash at the moment.

[qiangxue]

The User model class, the breadcrumbs in the view files, and many other tiny things. It's almost certain that if you drop this module in a different application, it won't work out of box.

Also because we are providing an application template here, there is no such need as to drop the user module in another application. If you want to reuse your existing user module work, you can polish the application template and start from there.

[schmunk42]

The User model class,

Currently provided by the module ;) - can be easily moved to the application

the breadcrumbs in the view files,

Would they throw an error? Since the app template supports this, it's a defacto standard, IMHO. Not really a big deal to be implemented in a nice way.

It's almost certain that if you drop this module in a different application, it won't work out of box.

Honestly "No. It would." - most other user modules, which have far more code and are more complex, all usually work just out of the box, eg. dektrium.

Also because we are providing an application template here, there is no such need as to drop the user module in another application. If you want to reuse your existing user module work, you can polish the application template and start from there.

The above PR "polishes" the app in a way, that this feature is build in. Now you can just drop in your modified module in your new application template - why won't you do that, especially if you've made changes to it.

[samdark]

Why not creating modified template instead of modified module?

[qiangxue]

No matter where the User model class is located, it will bring coupling between the module and the rest of the app, because the User model is a central piece in an application. Also the User model (and the DB table behind) could be implemented very differently in different apps, even though they do share many commonalities.

We can't say the breadcrumbs is a de facto standard without any interface governing it.

I'm not against implementing a user module as an extension by third parties. I'm just against doing it by the core team in the advanced app template at this moment, because I expect it will involve significant amount of time to make it reaching our standard. We do not want to release a half-baked product.

[tadaszelvys]

Guys, just enter yii2-user in github search and you'll see that everyone is making their own yii2 user module... i'm against adding this module to yii2 advanced/basic apps (even to github.com/yiisoft as some yii2-user), because it will be useless to many of us. Example included in advanced/basic apps is more than enough.

@schmunk42 if you want user module so bad, make it and add it to your github, whoever will want to use it will use it, why are you pushing it to everyone else. If you want to do a really great job - write a detailed manual on how yii2 authentication and authorisation works, what are the best practice and etc.

[schmunk42]

I'm not against implementing a user module as an extension by third parties. I'm just against doing it by the core team in the advanced app template at this moment, because I expect it will involve significant amount of time to make it reaching our standard. We do not want to release a half-baked product.

Both solutions belong to the application template and a module is not always a redistributeable extension. The standard should be the same whether the code is in a module or not.

But the problem lies on a different point I think. It's the way the developers see modules. Also from your feedback it looks to me like modules (even in the application) have to be developed in a much more stict way then extensions. But that is not the case, it is just a logical separation of code, exactly what the user management is.

Let me quote for your docs in 1.1; the statement is merely the same in the 2.0 guide.

"A module is a self-contained software unit that consists of models, views, controllers and other supporting components. In many aspects, a module resembles to an application. The main difference is that a module cannot be deployed alone and it must reside inside of an application. Users can access the controllers in a module like they do with normal application controllers.

Modules are useful in several scenarios. For a large-scale application, we may divide it into several modules, each being developed and maintained separately. Some commonly used features, such as user management, comment management, may be developed in terms of modules so that they can be reused easily in future projects."

Nowhere is encarved in stone that a module may not introduce any dependencies. In fact the word dependency is not even mentioned together with modules in the guides. Moreover, the guide says just "may" and "can".

Either the application depends on the User model from the user-module or vice-versa. And the User model implements UserIdentity isn't that simply the interface we need?

I can see the point that you do not want to create a user-extension under yiisoft and that is fine. But everyone who wants to replace the exisitng solution with an extension will end up in using a module. And the chance of leaving unused code behind is high, I just consider this not as a good practice.

What I am just saying: Combining the code in a logical entity is better than distributing it and having a dozen of files in different directories. btw: I even forgot the migration in console/migrations on the list above.

But I am repeating myself and I think can't convince you of the proposed way. So I'll have to do this in my application template and sadly waive the merges against the advanced-app.

[samdark]

Nowhere is encarved in stone that a module may not introduce any dependencies

"self-contained software unit"

Either the application depends on the User model from the user-module or vice-versa

Nope. Module cound intorduce an interface that user should implement in the model in order to use module. Then both app and module will depend on the interface and not on implementation. This way multiple user-related modules could be used w/o any conflict.

UserIdentity isn't enough. For example, comment module may require email, facebook account, username etc.

Application templates are just for one time kickstart. You've used it once and should not really care if it was updated or not and free to modify it as you want. I understand that you want to update your own application template from advanced app code but I doubt there will be much to update.

[schmunk42]

While I'd like the way with interfaces you propose very much, I also think that this approach will be very tricky to implement, especially with database models.

But do I get you right, when I think you mean interfaces like for example ICommentUser or IAccountUser which have to be implemented into the User model in order to use the corresponding module?

I also thought about your proposal to move the user related code to a namespace, but that leads to other points which may be confusing, IMO.

I understand that you want to update your own application template from advanced app code but I doubt there will be much to update.

I doubt that ;) but from a positive side ... there's still a place for Phundament.

PS: Thanks to all for your hard work, nice to have a RC version now.

[samdark]

Making things decoupled is tricky, correct but there's no way to avoid it if we're talking about redistributable modules. You understood me correct about interfaces.

Sure there's a place for Phundament. It's development style, spirit and reusability degree are a bit different from what's provided by the core.

[dynasource]

Schmunk: But the problem lies on a different point I think. It's the way the developers see modules. Also from your feedback it looks to me like modules (even in the application) have to be developed in a much more stict way then extensions. But that is not the case, it is just a logical separation of code, exactly what the user management is.

This is exactly how I see it.

Sam Dark: Application templates are just for one time kickstart.

I guess the developers who are pro or against are looking at the boiler template from a different perspective. Those who want to build many websites on the same core, prefer a user module. Those who want to start directly with customizing the platform to customers needs, prefer functionality de-modularized.

Although I see the logic behind the customization perspective, I think there are more advantages in separation:

• its far easier to see what the advanced template is all about
• its a logical separation of platform parts
• its easier and less time consuming to decouple the current user implementation
• its a modular approach and a smaller step to modular reuse
• its still a small step to customization (preferred by the people against the module)

[samdark]

It's not that simple:

• Where to put model? In the module? What if you want to add N fields? What if you want to login via Facebook? What if you want to login via username instead of email or vice versa?
• If user model isn't part of the module, but a thing from the app how to make sure it has all the fields required by the module?
• I want to add extra security to authentification. Is it part of the module?
• I want to customize login form, is it part of the module?

In order to satisfy such requirements you're either hardcoding stuff or relying on interfaces (which is OK if code is redistributed but could complicate app if it's not).

If you're building websites where all these things aren't required to be adjusted it's fine to have a module but if not then it's better not to.

Those who want to build many websites on the same core could use their own template. I think in this case there will be much more ready to use but specific things in it.

[dynasource]

Im still not convinced about the fact that the 'User' part is so complicated or unique per platform, that it has to be seen as a non-package.

With respect to your extended functionality, lets put it from this perspective: the architecture of Yii2 should enable one to easily solve the questions you are mentioning. If customization or extending a module is too hard for this, this could be an area where Yii2 could be further developed.

[samdark]

It is. Another common example is when user data is stored in two tables with hasOne relation i.e. user and profile. user has authentication stuff while profile has the rest: first name, last name, etc.

The quesetions I'm mentioning are easily solvable by refactoring and additional code handling each case. The problem is that this refactoring and code changes are different in each case.

[dynasource]

• Sounds like a profile module (btw. it wont be necessary in every project).
• Extra fields in the profile? Centralize the profile model (you know at forehand it is dynamic).
• Login via Facebook? Create a ExternalLogin module
• Extra security? Viable case. Insert a class property referring to the security class.
• Customization of forms? Overwrite by templates + hooks
• Relations between User & Profile module? This is something in Yii2 to provide more functionality for.
• etc etc.

[samdark]

Doing it all out of the box will complicate API significantly and it will be like the ones in CMSes such as Drupal: you have to learn it, you have to use hundreds of hooks, maintain modules order etc. I'd like to avoid it and let developers decide for themselves about what they really need.

[tom--]

No. I'm not going to repeat arguments I made above.

But I'll add this. If the user management in this app is pushed into a "module" then I, as a regular in #yii, would have to create factoids to help us educate those learning Yii that this module should not be used and that it represents a very bad example of a module. It would be, in my view, a counter-example -- an example of something that doesn't work as a module and to demonstrate that modules are a bad way to achieve mere organizational convenience. I am fairly confident that many of the other regulars will have a similar view.

Now I need to unsubscribe from this conversation so I don't get drawn into it again.

[samdark]

Agree.

[dynasource]

This discussion is not about creating a bad example of a module. This way of argumentation doesnt contribute to this discussion.

You all make it sound like a mission to the moon. Its just a User module with limited functionality around the identity class. I dont see strong arguments to understand that this could not be a self contained unit.

[klimov-paul]

@dynasource, as I already said above: spliting application into the modules as you suggest is only one of the possible project architecture. And there is no proof it is universal or better then other. This entire disscussion is witness to fact "module" and "not module" architecture are more or less equal. Why do we stick to "no module" approach? - because it has less classes, less files and has simplier structure - that is all.

Instead of arguing about creating user module in advanced app template, you should create your own template (or even several templates) and share them - to help the developers, which share your vision on the project architecture.

[klimov-paul]

P.S. whatever code we place at 'advanced' temlplate - it could not satisfy everyone.

[schmunk42]

@dynasource I think the perfect implementation (with interfaces, etc...) is actually bit like a mission to the moon. But that's also a theoretical discussion to me, because I see so many problems with it. PS: I'd love to hear some thoughts from your side about my implementation in Phundament - removed user related code and requiring user module from dektrium (could also be any other, just found this the best one so far).

---

It is also a fact (please correct me if I am wrong) that if you have a controller in your pluggable or redistributable code, you have to use a module. Otherwise you're unable to access the controller. And an implementation with actions is not pluggable, since you'd have to modify the controller files.

I'd say, that if you use modules, which share the User model, you end up in implementing a custom user class in your application anyway to satisfy all required interfaces. But you can still go this way when using a module.

A question to all, which extension would you consider a well implemented module (Yii1 or Yii2)?

[samdark]

@schmunk42 this one is close https://github.com/samdark/Yeeki/tree/master/app/modules/wiki

[motin]

A question to all, which extension would you consider a well implemented module (Yii1 or Yii2)?

For Yii 1.1, we used to use yii-user but have moved over to yii-account (github) which is far more extendable and well-architectured than yii-user.

[harry-flipkod]

As I see it - user module should contain only most generic user actions. Registration, forgot password, activation, reset password, login, generate password, create user..etc. Along that lines - the module should open public methods to let other parts of the application and/or modules to interact with it. User profile is application specific issue - some applications will want skype and linkedin ID in user profile while others will want address and zip code.. that's not something user module should take care of.