Approach discussion for user module

[kartik-v]

An initial take on SOD (of course we will jump into help each other anyway) - let know

• DB/Module config: Jointly
• Models: Jointly
• Basic user authentication: @robregonm
• Views, Widgets, & UI: @kartik-v
• RBAC integration, Email Integration, and Unit Tests: @schmunk42
• Remote & Social: @nineinchnick
• Documentation: @evercode1

[evercode1]

@kartik-v I'm 100% in. I will need a lot of guidance from you since I have not done this before, so please don't be shy about telling me what I need to do and when.

[robregonm]

Ok, looks fine for me.

[schmunk42]

RBAC and e-mail is fine, but I am not very experienced in Unit Tests.

Von meinem iPhone gesendet

Am 30.03.2014 um 15:21 schrieb Kartik Visweswaran notifications@github.com:

An initial take on SOD (of course we will jump into help each other anyway) - let know

DB/Module config: Jointly
Models: Jointly
Basic user authentication: @robregonm
Views, Widgets, & UI: @kartik-v
RBAC integration, Email Integration, and Unit Tests: @schmunk42
Remote & Social: @nineinchnick
Documentation: @evercode1
—
Reply to this email directly or view it on GitHub.

[kartik-v]

@schmunk42 no problems... I am bad at unit tests as well... and hence was looking for help here

@evercode1 would you be able to contribute in unit tests (we may not require documentation effort until we reach into an advanced coding stage)... or is anyone else better in carrying out tests?

Will need confirmation from @nineinchnick and we can start then... I suppose @nineinchnick and @robregonm can put more inputs on the user authentication piece since they have already coded it in their modules.

I personally will try to come up with a initial draft of Module Design and everyone can chip in...

[evercode1]

@kartik-v The short version:

I've never done any unit tests, my fear is I would drag down the timeline learning from scratch.

The longer version :)

Also, I looked at your docs for your existing social module and they are very impressive.
Your installation, configuration, and usage docs are concise, precise and easy to follow.

The reason I looked is I wanted to see what a good example looks like. I asked myself if I could do as good of a job on it and then I realized, in order to write docs correctly, one has to have full command of the code. This is a fairly deep extension that reaches into a lot of complex areas or at least they seem complex to me because of my level of experience.

The one thing I think I can bring to this is a beginner's perspective, which would help flush out what beginners might stumble over. Although I'm just a beginner programmer, I have a more advanced perspective on the industry which I've been a part of for 15 years.

I think this social extension is very important to Yii 2 and to the people who will want to use it. Having fully researched php frameworks, inlcuding Symfony and Laravel, I concluded Yii and especially Yii 2 was the best platform by far. I would love to contribute to this in any way I can. If you want me to start to learn unit testing, I will do it. Just point me in the right direction...

[nineinchnick]

Nobody likes to do unit tests 😄 I can do social, I did recently did an integration with Paypal using OAuth 2.0 and I tested Facebook on my demo site, I got the main scenarios covered.

[kartik-v]

Worked on an initial specification for the yii2-user Module. Kindly have a relook and let's finalize these configuration parameters.

[schmunk42]

@kartik-v Looks pretty sharp so far. If possible we may even simplify a few things, but we'll see.

[kartik-v]

Few more settings updated in the the yii2-user Module. Various small modifications have been incorporated: i.e. the password reset key settings, form view settings, global widget settings for each form that will be also made available as a widget (as a plugin into views).

[nineinchnick]

Do we really need the ability to override each view? Can't themes or setting view path be used for that?

[kartik-v]

Yes, views can be overridden with themes/view path as you said - this is the normal default. So we may not need configuration to override a view.

In addition, I had proposed separate widgets for each of those FORM_ areas. The configuration is for those. Advantage is that these can be directly embedded in any page the developer wants. For example LoginFormWidget or RegistrationFormWidget can be embedded on the home page at a particular location.

[nineinchnick]

Wouldn't such widgets have too many options? Even if there are only two inputs they need to have labels, error messages etc. Isn't a partial view simpler?

[kartik-v]

Not sure there should be many options (unless we want them to). We pick most of these information from the model attributes. Any labels/messages/hints should be translateable. This should work for most use cases. Think of it as if you have these prebuilt widgets, you can easily plug them anywhere in your layout without resorting to or recreating the entire view:

• LoginFormWidget
• SocialButtonsWidget
• RegistrationFormWidget

Inspite of all this, If the developer still feels this is not enough, he can entirely make his own view/layout and set it in the view map.

[evercode1]

prebuilt widgets such as these would be intuitive and easy to work with, similar to Kartik's exsiting social module. Very easy to implement and understand...

[kartik-v]

Sample use cases (which many can benefit from)

• Inline login form on the navbar
• Login form inside a modal dialog
• Control positioning of social buttons within the login process
• Can think of same for registration form - if you want to embed it merge - with an extended registration or the contact form etc.

A widget is easier to control (than renderPartial view). We assume bootstrap theme as default (like Yii) and can offer bootstrap styling options (like vertical, horizontal, or inline forms, and basic additional HTML attributes/options for styling). In fact we can reuse each widget code and embed in our default views.