IsDebugMode

There seems to be a difference in the way IsDebugMode() behaves on Lucee
4.5.1 vs ACF. It essentially does nothing but reflect the radio button in
the admin’s debugging.settings page; it returns true at all times even if
the request is not one that receives debug output. Given that radio button
being set to Yes,

  • IsDebugMode() if your IP is not in the administrator console’s
    debugging list: ACF *false */ Lucee true
  • IsDebugMode() if : ACF false /
    Lucee true

Is this by design? Has anyone else encountered this and cared enough to
find a workaround? (For those wondering, the reason I care is that I have
my error handler set to show me the “real” exception data instead of a
customer-friendly message when IsDebugMode(), a method which will no longer
work after migrating to Lucee.)

Hi,

Sounds like a bug to me, please raise an issue on the issue tracker:

https://luceeserver.atlassian.net

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.orgOn 14 June 2015 at 03:40, theprophecy <@theprophecy> wrote:

There seems to be a difference in the way IsDebugMode() behaves on Lucee
4.5.1 vs ACF. It essentially does nothing but reflect the radio button in
the admin’s debugging.settings page; it returns true at all times even if
the request is not one that receives debug output. Given that radio button
being set to Yes,

  • IsDebugMode() if your IP is not in the administrator console’s
    debugging list: ACF *false */ Lucee true
  • IsDebugMode() if : ACF false /
    Lucee true

Is this by design? Has anyone else encountered this and cared enough to
find a workaround? (For those wondering, the reason I care is that I have
my error handler set to show me the “real” exception data instead of a
customer-friendly message when IsDebugMode(), a method which will no longer
work after migrating to Lucee.)


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/0379a286-a0d7-4454-97cf-44b903475d6e%40googlegroups.com
https://groups.google.com/d/msgid/lucee/0379a286-a0d7-4454-97cf-44b903475d6e%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

In some times we decide against a compatibility to ACF, because we see a
functionality in ACF as a bug and not as a feature.
So the question for is not only “is this a bug”, it is also “what behaviour
is the best for the community”.

Interesting is the doc for this function with ACF:
“If debugging output is enabled in ColdFusion Administrator and has not
been overridden by setting the cfsettingtag showDebugOutput attribute to
No, the IsDebugMode function returns Yes; No, otherwise.”

So it does matches the functionality but the definition of “return” is
matching our implementation.
"Returns

True, if debugging mode is set in the ColdFusion Administrator; False if
debugging mode is disabled."

so it is unclear at best, one other way to do it would be, to match the ACF
functionality but mark this function as deprecated and add one that is more
precise in the functionality.

MichaOn Mon, Jun 15, 2015 at 9:11 AM, theprophecy <@theprophecy> wrote:

There’s value in maintaining compatibility with ACF, but beyond that the
name could be whatever you want.

The name of the function notwithstanding, the functionality in ACF is
useful in a wider range of scenarios; the limited functionality currently
in Lucee has a very narrow use case. That lost functionality is the reason
I brought it up. Whatever form it comes back in would be great.

On Monday, June 15, 2015 at 2:24:10 AM UTC-4, Micha wrote:

In my opinion this is a bug in ACF, the function name is “IsDebugMode”
what you only can enable in the admin, what you control with the tag
cfsetting is “showDebugOutput”, so only if the debug output is shown or
not. we could consider a function names “isDebugShown”. But if
“isDebugMode” is set to true, Lucee is logging the debug information in any
case and you can see it in the admin, so again “cfsetting-showDebugOutput”
has no influence on the debug mode.

Micha

On Sun, Jun 14, 2015 at 4:40 AM, theprophecy nickneck...@gmail.com wrote:

There seems to be a difference in the way IsDebugMode() behaves on Lucee
4.5.1 vs ACF. It essentially does nothing but reflect the radio button in
the admin’s debugging.settings page; it returns true at all times even if
the request is not one that receives debug output. Given that radio button
being set to Yes,

  • IsDebugMode() if your IP is not in the administrator console’s
    debugging list: ACF *false */ Lucee true
  • IsDebugMode() if : ACF false /
    Lucee true

Is this by design? Has anyone else encountered this and cared enough to
find a workaround? (For those wondering, the reason I care is that I have
my error handler set to show me the “real” exception data instead of a
customer-friendly message when IsDebugMode(), a method which will no longer
work after migrating to Lucee.)


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/0379a286-a0d7-4454-97cf-44b903475d6e%40googlegroups.com
https://groups.google.com/d/msgid/lucee/0379a286-a0d7-4454-97cf-44b903475d6e%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/03cad62e-fece-45c3-a8c6-738fe76ddfbb%40googlegroups.com
https://groups.google.com/d/msgid/lucee/03cad62e-fece-45c3-a8c6-738fe76ddfbb%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

Not to hijack the thread, but I’m still unsure what the vision is here for
the multiple dialects for Lucee? So I get that we’re going to have the
“new” dialect which breaks from ACF but is still based upon it (perhaps a
“cousin”?) but Micha has also stated that CFML compat is still vitally
important to the Lucee project and so we will always have the “CFML
compatibility dialect” … but we’ll still have incompats within that:
those that have been brought over from Railo days and then new ones too?
Doesn’t that then give us 2 divergent, not wholly compatible dialects?

It would be really helpful to get an official, clear, concise document on
what the vision for this language is moving forward. I think this would go
a long way to helping a lot of us understand what’s going on behind the
scenes and would provide better context for us to comment on threads like
this very one.On Monday, June 15, 2015 at 1:23:28 AM UTC-7, Adam Cameron wrote:

On Monday, 15 June 2015 09:10:07 UTC+1, Micha wrote:

I just tried to point out what is important for us to make the best
decision.

No, Micha, that wasn’t all you were doing. Most of what you wrote was
trying to justify yourself.

now that we know we need to decide what is the best for the future.

OK. So if we limit this discussion to “what’s best for the future”,my
suggestions would be:

For CFML
Follow Adobe’s precedent. There’s no gain to be had in making a variation
here. So I guess a bug should be raised (if one hasn’t been already).

For .lucee
You make a reasonable point that the naming of the function might be
misleading. I’m not sure if this is a function-naming thing or just a
documentation. thing though. Honest question: does my revision of the docs
for ColdFusion’s isDebugMode() remove the perceived lack of clarity? Is
that perhaps the path of least possible work here?

Going even further… perhaps a better API could be exposed for
debug-setting-management, eg a DebugService class which both reflects
current settings, as well as lets one with appropriate credentials to
modify them? I suppose the CFADminAPI has this already (does Lucee have
that? Never checked), but the API is a very clumsy one. It could simply be
something like:

DebugService.isDebugEnabled()
DebugService.isDebugOutputEnabled()
DebugService.getDebugIpAddresses()

etc

Moving from headless functions to a more OO approach would be a good
thing, perhaps?


Adam

Interesting is the doc for this function with ACF:

“If debugging output is enabled in ColdFusion Administrator and has not
been overridden by setting the cfsettingtag showDebugOutput attribute to
No, the IsDebugMode function returns Yes; No, otherwise.”

"Returns

True, if debugging mode is set in the ColdFusion Administrator; False if

debugging mode is disabled."

so it is unclear at best,

I have, btw, clarified the ColdFusion docs for isDebugMode()
https://wikidocs.adobe.com/wiki/display/coldfusionen/IsDebugMode. It now
reads:

Description

Determines whether debugging output will be displayed.
Returns

“Yes”, if debugging information will be output; otherwise “No”.
Usage

If debugging output is enabled in ColdFusion Administrator either globally
or for the current machine’s IP address and has not been overridden by
setting the cfsetting tag showDebugOutput attribute to No, the IsDebugModefunction
returns Yes; No, otherwise.

I’ve varied the “Description” and “Returns” sections to make them less
vague / ambiguous.On Monday, 15 June 2015 08:46:46 UTC+1, Adam Cameron wrote:


Adam

In some times we decide against a compatibility to ACF, because we see a
functionality in ACF as a bug and not as a feature.

If you were to be honest: is that what happened here, or did you just make
incorrect assumptions when implementing it, and got it slightly wrong?
(which surely is in the “hey: shit happens” category).

So the question for is not only “is this a bug”, it is also “what
behaviour is the best for the community”.

Your current implementation doesn’t value-add anything. However it does
cause a real-world cross compat issue. So the net worth of this variation
is a negative one.

If you want to vary the behaviour of this: vary it on .lucee to your
heart’s content.

Interesting is the doc for this function with ACF:
“If debugging output is enabled in ColdFusion Administrator and has not
been overridden by setting the cfsettingtag showDebugOutput attribute to
No, the IsDebugMode function returns Yes; No, otherwise.”

So it does matches the functionality but the definition of “return” is
matching our implementation.

Huh? (I mean “I don’t understand what you have written there”). CF does
exactly what it says in the docs you quote above. Lucee - apparently - does
not.

"Returns

True, if debugging mode is set in the ColdFusion Administrator; False if
debugging mode is disabled."

so it is unclear at best,

No, at best it does exactly what it claims to do, although the wording
could stand improvement.

It’s only if you read a latter statement without the context of the
previous statement that your can claim it’s unclear. Which is a bit of
contortion of how ppl usually go about things.

Basically you seem to be engaging in apologetics to justify (only to
yourself, I think) why you didn’t implement the function as per
ColdFusion’s specification (such as it is).

Look: there’s nothing wrong with having an implementation glitch. But
increasingly you (singular. I mean “Micha”) are twisting about the place
trying to justify why you’re actually right when - in reality - the
conversation is only taking place because you made a mistake at some point.

The problem here resides solely in Lucee and in your head, I’m afraid.

one other way to do it would be, to match the ACF functionality but mark
this function as deprecated and add one that is more precise in the
functionality

To me that is kinda adding more language clutter for no good reason.

You’re quibbling over the notion of “debug mode” and ascribing it a precise
definition that the inventors of the platform & language in question
clearly didn’t mean. It’s a slightly clumsy function name, but it’s not
like it’s the only clumsy function name in CFML. However it’s behaviour
makes sense in the context of the description in the docs. Which have been
the same for over a decade.

No-one gains anything from adding a similar-named function which does
something pretty much the same thing. That’s how PHP would “solve” a
problem.

You have your own language to “improve” in the .lucee thing, so perhaps
just fix the situation their, and don’t mess with CFML in such a way that
just leave the language slightly worse off.On Monday, 15 June 2015 08:22:07 UTC+1, Micha wrote:


Adam

It is always nice you know my intention better than I do, I always assumed
that is my wife’s job.

No special spousal telepathy needed, honey :wink:

I just read what you write. It’s easier that way.

What do you want for dinner tonight, btw?On Monday, 15 June 2015 09:33:11 UTC+1, Micha wrote:


Adam

xxx

Until today I was not aware that there is a differents between
Railo/Lucee and ACF, but now that we know we need to decide what is the
best for the future. I just tried to point out what is important for us to
make the best decision.

MichaOn Mon, Jun 15, 2015 at 9:46 AM, Adam Cameron <@Adam_Cameron> wrote:

On Monday, 15 June 2015 08:22:07 UTC+1, Micha wrote:

In some times we decide against a compatibility to ACF, because we see a
functionality in ACF as a bug and not as a feature.

If you were to be honest: is that what happened here, or did you just make
incorrect assumptions when implementing it, and got it slightly wrong?
(which surely is in the “hey: shit happens” category).

So the question for is not only “is this a bug”, it is also “what
behaviour is the best for the community”.

Your current implementation doesn’t value-add anything. However it does
cause a real-world cross compat issue. So the net worth of this variation
is a negative one.

If you want to vary the behaviour of this: vary it on .lucee to your
heart’s content.

Interesting is the doc for this function with ACF:
“If debugging output is enabled in ColdFusion Administrator and has not
been overridden by setting the cfsettingtag showDebugOutput attribute to
No, the IsDebugMode function returns Yes; No, otherwise.”

So it does matches the functionality but the definition of “return” is
matching our implementation.

Huh? (I mean “I don’t understand what you have written there”). CF does
exactly what it says in the docs you quote above. Lucee - apparently - does
not.

"Returns

True, if debugging mode is set in the ColdFusion Administrator; False if
debugging mode is disabled."

so it is unclear at best,

No, at best it does exactly what it claims to do, although the wording
could stand improvement.

It’s only if you read a latter statement without the context of the
previous statement that your can claim it’s unclear. Which is a bit of
contortion of how ppl usually go about things.

Basically you seem to be engaging in apologetics to justify (only to
yourself, I think) why you didn’t implement the function as per
ColdFusion’s specification (such as it is).

Look: there’s nothing wrong with having an implementation glitch. But
increasingly you (singular. I mean “Micha”) are twisting about the place
trying to justify why you’re actually right when - in reality - the
conversation is only taking place because you made a mistake at some point.

The problem here resides solely in Lucee and in your head, I’m afraid.

one other way to do it would be, to match the ACF functionality but mark
this function as deprecated and add one that is more precise in the
functionality

To me that is kinda adding more language clutter for no good reason.

You’re quibbling over the notion of “debug mode” and ascribing it a
precise definition that the inventors of the platform & language in
question clearly didn’t mean. It’s a slightly clumsy function name, but
it’s not like it’s the only clumsy function name in CFML. However it’s
behaviour makes sense in the context of the description in the docs. Which
have been the same for over a decade.

No-one gains anything from adding a similar-named function which does
something pretty much the same thing. That’s how PHP would “solve” a
problem.

You have your own language to “improve” in the .lucee thing, so perhaps
just fix the situation their, and don’t mess with CFML in such a way that
just leave the language slightly worse off.


Adam


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/a1563bb6-dd8b-44bb-8612-2865a6582379%40googlegroups.com
https://groups.google.com/d/msgid/lucee/a1563bb6-dd8b-44bb-8612-2865a6582379%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

In my opinion this is a bug in ACF, the function name is “IsDebugMode” what
you only can enable in the admin, what you control with the tag cfsetting
is “showDebugOutput”, so only if the debug output is shown or not. we could
consider a function names “isDebugShown”. But if “isDebugMode” is set to
true, Lucee is logging the debug information in any case and you can see it
in the admin, so again “cfsetting-showDebugOutput” has no influence on the
debug mode.

MichaOn Sun, Jun 14, 2015 at 4:40 AM, theprophecy <@theprophecy> wrote:

There seems to be a difference in the way IsDebugMode() behaves on Lucee
4.5.1 vs ACF. It essentially does nothing but reflect the radio button in
the admin’s debugging.settings page; it returns true at all times even if
the request is not one that receives debug output. Given that radio button
being set to Yes,

  • IsDebugMode() if your IP is not in the administrator console’s
    debugging list: ACF *false */ Lucee true
  • IsDebugMode() if : ACF false /
    Lucee true

Is this by design? Has anyone else encountered this and cared enough to
find a workaround? (For those wondering, the reason I care is that I have
my error handler set to show me the “real” exception data instead of a
customer-friendly message when IsDebugMode(), a method which will no longer
work after migrating to Lucee.)


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/0379a286-a0d7-4454-97cf-44b903475d6e%40googlegroups.com
https://groups.google.com/d/msgid/lucee/0379a286-a0d7-4454-97cf-44b903475d6e%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

i like it burnt like my wife does ;-)On Mon, Jun 15, 2015 at 10:37 AM, Adam Cameron <@Adam_Cameron> wrote:

On Monday, 15 June 2015 09:33:11 UTC+1, Micha wrote:

It is always nice you know my intention better than I do, I always
assumed that is my wife’s job.

No special spousal telepathy needed, honey :wink:

I just read what you write. It’s easier that way.

What do you want for dinner tonight, btw?


Adam

xxx


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/615c9544-9475-4cd0-b2fe-4d184e149d01%40googlegroups.com
https://groups.google.com/d/msgid/lucee/615c9544-9475-4cd0-b2fe-4d184e149d01%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

I just tried to point out what is important for us to make the best
decision.

No, Micha, that wasn’t all you were doing. Most of what you wrote was
trying to justify yourself.

now that we know we need to decide what is the best for the future.

OK. So if we limit this discussion to “what’s best for the future”,my
suggestions would be:

For CFML
Follow Adobe’s precedent. There’s no gain to be had in making a variation
here. So I guess a bug should be raised (if one hasn’t been already).

For .lucee
You make a reasonable point that the naming of the function might be
misleading. I’m not sure if this is a function-naming thing or just a
documentation. thing though. Honest question: does my revision of the docs
for ColdFusion’s isDebugMode() remove the perceived lack of clarity? Is
that perhaps the path of least possible work here?

Going even further… perhaps a better API could be exposed for
debug-setting-management, eg a DebugService class which both reflects
current settings, as well as lets one with appropriate credentials to
modify them? I suppose the CFADminAPI has this already (does Lucee have
that? Never checked), but the API is a very clumsy one. It could simply be
something like:

DebugService.isDebugEnabled()
DebugService.isDebugOutputEnabled()
DebugService.getDebugIpAddresses()

etc

Moving from headless functions to a more OO approach would be a good thing,
perhaps?On Monday, 15 June 2015 09:10:07 UTC+1, Micha wrote:


Adam

i like it burnt like my wife does :wink:

As we will no-doubt be (deservedly) burning in hell after this
conversation, this should be easily achievable.

See you tonight.On Monday, 15 June 2015 09:40:28 UTC+1, Micha wrote:


Adam

There’s value in maintaining compatibility with ACF, but beyond that the
name could be whatever you want.

The name of the function notwithstanding, the functionality in ACF is
useful in a wider range of scenarios; the limited functionality currently
in Lucee has a very narrow use case. That lost functionality is the reason
I brought it up. Whatever form it comes back in would be great.On Monday, June 15, 2015 at 2:24:10 AM UTC-4, Micha wrote:

In my opinion this is a bug in ACF, the function name is “IsDebugMode”
what you only can enable in the admin, what you control with the tag
cfsetting is “showDebugOutput”, so only if the debug output is shown or
not. we could consider a function names “isDebugShown”. But if
“isDebugMode” is set to true, Lucee is logging the debug information in any
case and you can see it in the admin, so again “cfsetting-showDebugOutput”
has no influence on the debug mode.

Micha

On Sun, Jun 14, 2015 at 4:40 AM, theprophecy <nickneck...@gmail.com <javascript:>> wrote:

There seems to be a difference in the way IsDebugMode() behaves on Lucee
4.5.1 vs ACF. It essentially does nothing but reflect the radio button in
the admin’s debugging.settings page; it returns true at all times even if
the request is not one that receives debug output. Given that radio button
being set to Yes,

  • IsDebugMode() if your IP is not in the administrator console’s
    debugging list: ACF *false */ Lucee true
  • IsDebugMode() if : ACF false /
    Lucee true

Is this by design? Has anyone else encountered this and cared enough to
find a workaround? (For those wondering, the reason I care is that I have
my error handler set to show me the “real” exception data instead of a
customer-friendly message when IsDebugMode(), a method which will no longer
work after migrating to Lucee.)


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/0379a286-a0d7-4454-97cf-44b903475d6e%40googlegroups.com
https://groups.google.com/d/msgid/lucee/0379a286-a0d7-4454-97cf-44b903475d6e%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

yeah with introduction of the Lucee dialect the position of the CFML
dialect also change, compatibilty to ACF get even more important. but that
does not mean we will follow every stupidity behaviour ACF has on every
price without thinking about it.

Best example is passing arrays to functions “by value”, as long i have
something to say Lucee will never follow that behaviour in the CFML
dialect, even we have an incompatibility here. but like i pointed out
before in this thread:
So the question for is not only “is this a bug”, it is also “what
behaviour is the best for the community”.

For me the answer here is very clear, that acf behaviour is not in the
interest of the community, because ACF clones ALWAYS any array that is
passed to a function or comes back from a function what of course slow down
the process in 99.9…% of the cases for no reason.

in that case i agree that we should follow ACF on this, even i was first
thinking that this is a bug in ACF, but even it is it will not affect the
majority of the users anyway.

So compatibility yes, but not at any price

MichaOn Mon, Jun 15, 2015 at 10:39 AM, ADK <@ADK> wrote:

Not to hijack the thread, but I’m still unsure what the vision is here for
the multiple dialects for Lucee? So I get that we’re going to have the
“new” dialect which breaks from ACF but is still based upon it (perhaps a
“cousin”?) but Micha has also stated that CFML compat is still vitally
important to the Lucee project and so we will always have the “CFML
compatibility dialect” … but we’ll still have incompats within that:
those that have been brought over from Railo days and then new ones too?
Doesn’t that then give us 2 divergent, not wholly compatible dialects?

It would be really helpful to get an official, clear, concise document on
what the vision for this language is moving forward. I think this would go
a long way to helping a lot of us understand what’s going on behind the
scenes and would provide better context for us to comment on threads like
this very one.

On Monday, June 15, 2015 at 1:23:28 AM UTC-7, Adam Cameron wrote:

On Monday, 15 June 2015 09:10:07 UTC+1, Micha wrote:

I just tried to point out what is important for us to make the best
decision.

No, Micha, that wasn’t all you were doing. Most of what you wrote was
trying to justify yourself.

now that we know we need to decide what is the best for the future.

OK. So if we limit this discussion to “what’s best for the future”,my
suggestions would be:

For CFML
Follow Adobe’s precedent. There’s no gain to be had in making a variation
here. So I guess a bug should be raised (if one hasn’t been already).

For .lucee
You make a reasonable point that the naming of the function might be
misleading. I’m not sure if this is a function-naming thing or just a
documentation. thing though. Honest question: does my revision of the docs
for ColdFusion’s isDebugMode() remove the perceived lack of clarity? Is
that perhaps the path of least possible work here?

Going even further… perhaps a better API could be exposed for
debug-setting-management, eg a DebugService class which both reflects
current settings, as well as lets one with appropriate credentials to
modify them? I suppose the CFADminAPI has this already (does Lucee have
that? Never checked), but the API is a very clumsy one. It could simply be
something like:

DebugService.isDebugEnabled()
DebugService.isDebugOutputEnabled()
DebugService.getDebugIpAddresses()

etc

Moving from headless functions to a more OO approach would be a good
thing, perhaps?


Adam


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/eba9ab58-1c36-4a15-9f4d-8ca90de9cd72%40googlegroups.com
https://groups.google.com/d/msgid/lucee/eba9ab58-1c36-4a15-9f4d-8ca90de9cd72%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

It is always nice you know my intention better than I do, I always assumed
that is my wife’s job.

I agree on your approach about how we should handle this, of course moving
away from functions to objects with methods is a general decision that is
worth thinking about it (lang.lucee.org).

MichaOn Mon, Jun 15, 2015 at 10:23 AM, Adam Cameron <@Adam_Cameron> wrote:

On Monday, 15 June 2015 09:10:07 UTC+1, Micha wrote:

I just tried to point out what is important for us to make the best
decision.

No, Micha, that wasn’t all you were doing. Most of what you wrote was
trying to justify yourself.

now that we know we need to decide what is the best for the future.

OK. So if we limit this discussion to “what’s best for the future”,my
suggestions would be:

For CFML
Follow Adobe’s precedent. There’s no gain to be had in making a variation
here. So I guess a bug should be raised (if one hasn’t been already).

For .lucee
You make a reasonable point that the naming of the function might be
misleading. I’m not sure if this is a function-naming thing or just a
documentation. thing though. Honest question: does my revision of the docs
for ColdFusion’s isDebugMode() remove the perceived lack of clarity? Is
that perhaps the path of least possible work here?

Going even further… perhaps a better API could be exposed for
debug-setting-management, eg a DebugService class which both reflects
current settings, as well as lets one with appropriate credentials to
modify them? I suppose the CFADminAPI has this already (does Lucee have
that? Never checked), but the API is a very clumsy one. It could simply be
something like:

DebugService.isDebugEnabled()
DebugService.isDebugOutputEnabled()
DebugService.getDebugIpAddresses()

etc

Moving from headless functions to a more OO approach would be a good
thing, perhaps?


Adam


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/3cd2afd6-3923-49fc-a9ee-4e835d638338%40googlegroups.com
https://groups.google.com/d/msgid/lucee/3cd2afd6-3923-49fc-a9ee-4e835d638338%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.