Standardize false values for string fields

[deepu105]

Currently we use a mix of false and no to disable things. We should have a standard way of doing this with either false or no everywhere.

For example see serviceDiscoveryType and cacheProvider

application {
  config {
    baseName notification,
    applicationType microservice,
    packageName com.jhipster.demo.notification,
    serviceDiscoveryType false,
    authenticationType jwt,
    databaseType mongodb,
    devDatabaseType mongodb,
    prodDatabaseType mongodb,
    cacheProvider no,
    enableHibernateCache false,
    buildTool gradle,
    serverPort 8083
  }
  entities Notification
}

[deepu105]

I think we should stick with no or none for falsey values instead of false

[MathieuAA]

Agreed. This would be a breaking change if we don't handle this right.

[deepu105]

its already broken actually, so i'm doing a fix now to restore old behaviour

[deepu105]

closed the wrong one

[MathieuAA]

This concerns everyone @jhipster/developers. I agree with @deepu105's proposal.
false will also be accepted, as long as it concerns a boolean.

If everyone's okay with no, please say so :) If you have any objection, please reconsider tell us why.

---

Seems none is better!

[DanielFran]

I'd prefer none (example for cache provider) when it is not a boolean.

But what is important is the consistancy, so if no is the one choosen it is not a problem.

[murdos]

FYI there's a related discussion on jhipster/generator-jhipster#8608
For non boolean parameter none seems more appropriate.
For boolean parameter I've no problem with true/false. But if we choose no, the opposite value should also be changed from true to yes.

[deepu105]

Booleans can remain true/false, I'm only talking about String with no/none/false

[murdos]

@MathieuAA could you do that for JHipster V6? I could handle the changes in generator-jhipster if needed, but I'm not sure how/where things should be changed here.

[MathieuAA]

@murdos Yep, I'll find time this week to do it.

[murdos]

@MathieuAA : any update on the subject? If you don't have the time, could you tell me where would be the best place in the code to add the standardization of the provided value, as suggested by @deepu105 :
jhipster/generator-jhipster#8608 (comment)

[MathieuAA]

Yeah I got side-tracked this past few weeks.
You can create an utils file for this, like OptionUtils, that has the method mentioned.

[MathieuAA]

I think this is a good time to do it, I want to release JCore v6 (including quite a few breaking changes) and this issue is just yelling at me to get closed.
I'm gonna see what needs to be done for this one.

[deepu105]

But since JCore is so integral to JHipster may be we should do breaking changes in grammar along with next major version of JHipster. May be first we should merge jcore to Jhipster

…

On Sat, 2 Nov 2019, 8:17 pm Mathieu ABOU-AICHI, ***@***.***> wrote: I think this is a good time to do it, I want to release JCore v6 (including quite a few breaking changes) and this issue is just yelling at me to get closed. I'm gonna see what needs to be done for this one. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#283?email_source=notifications&email_token=AAIOKF2AQRUZHVJQOIVXC7TQRW74ZA5CNFSM4GDCISKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5B4ZA#issuecomment-549068388>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIOKF56SKEZBHDAD3JTOYTQRW74ZANCNFSM4GDCISKA> .

[MathieuAA]

Agreed.
About the merging: I give up on lerna. It stops parsing a package's commits after a while, giving no clear error message. Maybe someone has to try again, or we could look for other solutions.

[MathieuAA]

Closing this in favor of jhipster/generator-jhipster#8608.