getApplicationSettings( onlySupported=boolean ) 6.0.0.317

language
1

by default, getApplicationSettings() returns all the values and functions in the this scope from the Application.cfc constructor,

LDEV-4333 add getApplicationSettings( onlySupported=boolean )

GetApplicationSettings() :: Lucee Documentation (changes not visible yet, docs are currently for 5.3.10)

  1. it adds all the supported settings from the Application
  2. then it adds any functions (UDFs) which weren’t set from step 1
  3. then it adds any other keys which weren’t set from steps 1 or 2

We have added in Lucee 6 an onlySupported boolean argument which optionally skips (unsupported) values from step 3

If false (default)

  • all supported Application settings, plus any other values and functions defined in the Application.cfc constructor are returned.

If True

  • Only Application settings for Lucee Core are returned
  • Any settings for Extensions may not be returned (TBD)
  • Any Application.cfc setting which has no effect on Lucee Core will be not returned

Note

  • Settings defined using aliases are also returned under the default setting name (i.e settings may be duplicated)

i.e. this.useJavaAsRegexEngine=true; is an alias for this.regex.type="java";

When onlySupported is true, only regex would be returned, if useJavaAsRegexEngine alias was used

This is useful to check if you have misconfigured (typos) in your application settings which aren’t being picked up and used by Lucee.

This can be useful when debugging, for example when you have a typo like this.datasoures which would be ignored by Lucee, but still returned by getApplicationSettings()

2 Likes
2

Given the docs for getApplicationSettings say this:

The returned struct contains the following data

[concrete list of expectations]

Wasn’t it just a bug that it wasn’t doing what this new behaviour implements anyhow? The function is clearly intended to return the app settings, not “all the this scope of the Application object”.

It seems to me the better solution here would be to simply make it do what it claimed to do, and don’t return all the cruft it wasn’t intended to do.

I would not implement this new boolean param to make it do what it was supposed to in the first place: I’d just fix the bug. plus in the process I’d ditch the other param too, as that was just a a partial “fix” for the situation too, by the looks?

As for potential “backwards compat” concerns… this is in 6.x, a major release, so it would be completely fine to have a bugfix that is a “breaking change”. I mean almost all bugfixes are a breaking change anyhow, really, right? Given a bugfix is generally gonna change the existing behaviour of whatever it is a fix for…

I don’t think this is moving the language forward.

3

Given the various existing caveats listed like extension settings not being returned (that’s going to need some additional plumbing in the future) and aliases, your proposal would mean that you couldn’t even get all the application settings?

4

No, my proposal is that the function should do what it’s documented to do / intended to do, which it’s currently clearly not. Pretty sure my initial wording was clear on that mark.

The function is getApplicationSettings. Application settings. And it’s clearly documented what that means in the docs I pointed to. So that’s what it should do. And all it should do. Not “oh and does something different if you pass it this flag param”. That’s poor practice.

If extensions need to expose settings… cool… that’s something else. And probably down to the extension codebase to deal with. Or a function getExtensionSettings or something. But I don’t think it’s really Lucee’s job, nor handling it in a global way is very good either.

Equally if you additionally need a function getAllApplicationPublicStuff (might wanna work on that name ;-)), then that is something different too. It’s different from getApplicationSettings, and it’s different from getExtensionSettings.

It seems to me that there are perhaps two issues here:

  • getApplicationSettings is not doing what it’s supposed to.
  • fixing that first point shows at least a perceived additional shortfall that there is no functionality along the lines of getAllApplicationPublicStuff, and that possibly needs implementing too.

Rolling both of those into one function that is clearly intended to only do one of those things is not a great solution.

Only semi-related… I actually challenge the merit of the practice of parking “other stuff” in the this scope of the Application. It’s probably not a good way of dealing with whatever needs to be done. EG: an extension should manage / expose its own settings, not dump them in some global space; variables needing to be accessed outside Application’s own code are probably better placed in application / session / request scopes as appropriate, or managed more thoughtfully entirely (as properties of an object etc). I don’t know that it’s for Lucee to enable random dumping of stuff in the Application’s this scope because one can’t be arsed working out where better to put it.

5

I’d like to +1 (is that a thing?) for fixing, getApplicationSettings to simply do what it says on the box.

Then copy/paste as appropriate the code that could become, getAllApplicationPublicStuff.
Though : I have no opinion about whether or not point 2 should exist or not.

1 Like