Making messages more customizable

[Justin Forseth]

We are already able to customize the dictionary of messages simplelogin flashes. However, there is no easy way to:

1. Toggle messages on and off
2. Customize the categories of the flashes

Toggling could be useful if the user has implemented a custom login checker function, or if the user doesn't want to flash these messages. Custom categories could be useful for projects structured with different categories.
For example, if I have a project that uses:
'success'
'alert'
'info'
'warning'
and I try to use flask_simplelogin, the categories:
'danger'
'primary'
etc, could break an existing project structure.

I suggest something along the lines of:

show_messages = True

that can be configured just like the message dictionary.
Then, all flashes could be place inside an if statement, like this:

if show_messages:
      flash(self.messages['someKey'], 'someCategory')

I'm not quite as sure how custom categories would work. Parts of the source code went over my head.
For all I know, this could already be possible. If so, I'd suggest some updates to the README to clarify.
If not, maybe a nested dictionary could be used?

messages = {
'login-success', {'message':'someMessage', 'category':'someCategory'},
}

[Justin Forseth]

I don't know, I'm still a beginner, but I'd love to hear your thoughts on this, and to contribute where I can.

[Eduardo Cuducos]

I do think it's a great idea and I'm willing to support anyone in developing this.

I have two minor comments, though:

1. I think that aligned with every other simple (one value) customization we have, I would encourage a setting SIMPLELOGIN_SHOW_MESSAGE instead of using an argument in the SimpleLogin(show_messages=False).
2. Regarding the messages, I'd go for a namedtuple instead of a dictionary, that is to say

messages = {
    'login-success': Message('someCategory', 'someMessage')
}

instead of:

messages = {
    'login-success', {'message':'someMessage', 'category':'someCategory'},
}

[Eduardo Cuducos]

Just thinking out loud: maybe the same message argument could be used to turn the feature on/off.

1. SimpleLogin(app), implying messages = None, uses the defaults, which if show messages as defined in the package
2. SimpleLogin(app, messages=messages) uses the customized messages passed
3. SimpleLogin(app, messages=False) turns off the messaging feature

messages value/type	On/Off	Message texts
None	On	Default
dict	On	Customized
False	Off	N/A

[Justin Forseth]

I like that idea. That's a lot clearer and simpler way of doing it. My only concern is with access_denied and auth_error. I didn't realize those were return statements, I assumed the were all flash()

I guess it would make the most sense just the leave them as is, but it seems inconsistent, and harder to explain that way.

Once I've written some code, how do I share it with you? Is that what a pull request is for? Or is that only when everything is finished? Obviously I can't commit to a new branch, right?

[Eduardo Cuducos]

Once I've written some code, how do I share it with you? Is that what a pull request is for?

Yes, that is what pull requests are for 🤘

Or is that only when everything is finished?

You can open a PR (pull request) as a draft (or work in progress), that is great for a more interactive cycle of feedback and development.

Obviously I can't commit to a new branch, right?

Actually that's the best strategy to create a pull request! I'll try to summarize the steps:

1. Fork this repository in your account
2. Clone your fork locally
3. Create a new branch for you to work on this features
4. Get started, yay
5. Commit progress to this new branch
6. Push changes to your remote repository (still in the feature branch)
7. At this point you can go back to GitHub page and open the PR
8. Also, once you open the PR, every commit pushed to that featured branch will be automatically included in the opened PR

[Eduardo Cuducos]

Closed by #18