'[2.0-java] Why I can't define a default-value by configuration.

[GrailsDeveloper]

Hi,

I'm starting to migrate some stuff from play 1.0 to play 2.0. There is one thing I found really annoying. In Play 1.0 I could say Play.configuration.get("myProp", "DefaultValue"). What is the reason that it is missing in 2.0? For me it Look like a must have. Now my code is cluttered with if (value== null) then;

Shall I create a ticket for this.

Niels

[Leon Radley]

I added the possibility to specify a default value in this pull request.

https://github.com/playframework/Play20/pull/254

Let's hope the core developers include it :)

[Guillaume Bort]

Yes I agree it is useful. 

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/Pl_nM89StTMJ.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[GrailsDeveloper]

Tanks this is a nice solution. I thought to create a pull-request, but the orElse-function is very nice. My solution would be much more complicated. The only thing I missed is test, but I don't find any test for the existing functionality so I guess it would be OK.

[Havoc Pennington]

Hi,

fwiw, the way the underlying https://github.com/typesafehub/config
library is set up should make this unnecessary in most cases.

The basic approach is:

- create a reference.conf containing your default values
- the API throws an exception if a value is not set (which would
normally indicate a broken classpath or deployment)

There are cases where this is awkward (basically, cases where you have
a dynamic config setting e.g. a config key based on some runtime
value) but even in those cases you can arrange to merge the dynamic
config with a static set of defaults up front using withFallback(),
thereby ensuring that all settings have a value.

mySettings.withFallback(defaultSettings)

The fundamental problem with an API like:

Play.configuration.get("myProp", "DefaultValue")

is that "DefaultValue" has to be cut-and-pasted to any location that
gets "myProp". Another problem with it is that people have to read
source code to learn what the default values are, instead of seeing
them all in a reference.conf.

Another case is when you want a config setting to be optional (i.e.
null is a valid setting for it). That is a bit different situation and
then handling null or Option is necessary.

Anyway the README at https://github.com/typesafehub/config and the
examples/ directory for that may be helpful.

Havoc

[Leon]

This is awesome!

I had no ideé it worked that way. thanks!

Should we discard the pull request, and add this to the documentation instead?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

[GrailsDeveloper]

Not sure if I really get it. First the methods which are provided by  https://github.com/typesafehub/config  are not accessible for the config. So with fallback doesn't work. In my case I want to create a submodule which should be configurable. Is it correct if I define a  reference.conf in the submodule conf-folder(?) then I will always get this values except in application.conf has different values?

Niels

[Leon Radley]

According to the section on "standard behaviour" here https://github.com/typesafehub/config
It will look for all files named reference.conf on the class path.

This means play will look for all files. So the sub project layout should work for you out of the box if I understand it correctly.

[GrailsDeveloper]

This was my understanding too, how ever I'm unsure if there exists more then one of such file or if the play-team changed this behavior. Has anyone test it?

Niels

[Havoc Pennington]

Hi,

On Mon, Apr 23, 2012 at 11:32 AM, GrailsDeveloper
<openso...@googlemail.com> wrote:
> Not sure if I really get it. First the methods which are provided by
> https://github.com/typesafehub/config  are not accessible for the config.

You can always use Play.current.configuration.underlying

So for example if you wanted to you could do:

val myDefaults = ConfigFactory.parseResources("something.conf")
val myModuleConfig =
Play.current.configuration.underlying.withFallback(myDefaults)
val whatever = myModuleConfig.getString("whatever")

However I'm not sure that is necessary, if you just put a
reference.conf on the classpath I would expect that it works fine. The
key is to be sure it's on the classpath and at a root resource
directory (not inside any Java package).

> So
> with fallback doesn't work. In my case I want to create a submodule which
> should be configurable. Is it correct if I define a  reference.conf in the
> submodule conf-folder(?) then I will always get this values except in
> application.conf has different values?

I'm not sure how the conf folder is handled; if it ends up on the
classpath then putting reference.conf in there ought to work. If it
isn't on the classpath you might have to use src/main/resources
instead of the conf folder, or something like that.

Havoc

[GrailsDeveloper]

Hi,

I can't use underlying, because I want to code in Java, there is no such option. I assume that it will work and if I reach the point where I get trouble, I will see how to solve it.

Niels

Am Dienstag, 24. April 2012 13:58:56 UTC+2 schrieb Havoc Pennington:

Hi,

On Mon, Apr 23, 2012 at 11:32 AM, GrailsDeveloper

[Havoc Pennington]

I'm sure there's a way to get to 'underlying' in Java, just a question
of how hacky it is ;-) but yes hopefully you won't need it.

Havoc

[GrailsDeveloper]

Well I think then it would be better to make it available in the java-api.

Thanks for  you hints.

Niels

Am Mittwoch, 25. April 2012 14:32:53 UTC+2 schrieb Havoc Pennington:

I'm sure there's a way to get to 'underlying' in Java, just a question
of how hacky it is ;-) but yes hopefully you won't need it.

Havoc

On Tue, Apr 24, 2012 at 2:27 PM, GrailsDeveloper

[GrailsDeveloper]

Please let the pull-request open. Today I have the following use-case. I try to get a secret from configuration. If I don't get one, I choose the application secret. This can't be done with the other approach.

Niels

Am Montag, 23. April 2012 15:28:58 UTC+2 schrieb Leon Radley:

This is awesome!

I had no ideé it worked that way. thanks!

Should we discard the pull request, and add this to the documentation instead?

To post to this group, send email to play-framework@googlegroups.com.
To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.