Fw: widgetVerbose

[BJ Freeman]

+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component level.


Hans Bakker sent the following on 9/19/2011 2:14 AM:

> If i use the widget comments option i want it to be generally applied
> and taken away depending on the properties setting. I do not want to
> find out that somewhere it is not following the setting, then have to
> dig in the code and find out that is, because somebody put an
> undocumented override somewhere by default as happened the first time.
> Bird and google checkout is fine.
>
> I think how it is implemented now is fine. I hope i commented now
> enough?
>
> Regards,
> Hans
>
> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>> Hans,
>>
>> Jacques gave some examples of where an override is currently used and
>> why it is needed. Could you give us another reason besides "i think an
>> override is an overkill" - like a reason based on a design issue or a
>> real-world problem?
>>
>> -Adrian
>>
>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>> I as sorry i do not see the problem here.....
>>>
>>> as long as the properties setting in the trunk will show or hide all
>>> widget comments (so in the trunk NO override) then it is fine.
>>>
>>> why? because i think an override is an overkill anyway....
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>> Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that
>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example
>>>> in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason..
>>>>
>>>> In other word I guess Hans expect widget.verbose in the properties file to be false...
>>>>
>>>> Jacques
>>>>
>>>> From: "Adrian Crum"<[hidden email]>
>>>>> Let's see if we can bring this to a happy ending.
>>>>>
>>>>> If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are
>>>>> shut off.
>>>>>
>>>>> If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but
>>>>> it can be overridden in web.xml and in the context Map.
>>>>>
>>>>> Will that work for everyone?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
>>>>>> I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of
>>>>>> always rendering as html comments.
>>>>>> As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always used
>>>>>> this feature in a very rough way (enable all or disable all); however I can understand the we may want to avoid that (when
>>>>>> widget.properties.enableBoundaryComments == false) the comments are enabled by passing a URL parameter to the screen.
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> Someone I work with suggested:
>>>>>>>
>>>>>>> I have to point out though that I kind of agree with the way David put it in that the "false" setting could have a priority,
>>>>>>> i.e. it's like in security permissions where "deny" has precedence over allow, so if you set it in widget.properties to false
>>>>>>> then you're sure comments will never be enabled anywhere... security-wise it makes sense despite the comment about qc...
>>>>>>>
>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>
>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>         || web.xml.enableBoundaryComments == false
>>>>>>>         || context.enableBoundaryComments == false) {
>>>>>>>     return false;
>>>>>>> } else { // This is the solution Scott wrote, but use overriding settings only for null and true values
>>>>>>>     if (context.enableBoundaryComments != null) return context.enableBoundaryComments;
>>>>>>>     if (web.xml.enableBoundaryComments != null) return web.xml.enableBoundaryComments;
>>>>>>>     if (widget.properties.enableBoundaryComments != null) return widget.properties.enableBoundaryComments;
>>>>>>>     return false;
>>>>>>> }
>>>>>>>
>>>>>>> Could probably rewrite that to be less redundant but you get the idea...
>>>>>>>
>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what do you think?
>>>>>>>
>>>>>>> Also my colleague also wrote:
>>>>>>> Only thing I have to add is that I didn't see anyone address the issue that HTML comments are outputted for CSV (because there's
>>>>>>> no<csv>   element and you have to use<html>) element. No matter what widget.verbose is set to, there should never be HTmL
>>>>>>> comments outputted for csv. so this only addresses half the bugs...
>>>>>>>
>>>>>>> We have no patches so far...
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Dimitri Unruh wrote:
>>>>>>>> +1
>>>>>>>>
>>>>>>>>
>>>>>>>> Dimitri Unruh
>>>>>>>> Consultant AEW
>>>>>>>> Lynx-Consulting GmbH
>>>>>>>> Johanniskirchplatz 6
>>>>>>>> 33615 Bielefeld
>>>>>>>> Deutschland
>>>>>>>> Fon: [phone]
>>>>>>>> Fax: [phone]
>>>>>>>> Mobil: [phone]
>>>>>>>>
>>>>>>>>
>>>>>>>> Company and Management Headquarters:
>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>
>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>
>>>>>>>>
>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>> DSAG-Jahreskongress
>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
>>>>>>>>
>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven Informations- und Erfahrungsaustausch rund um das
>>>>>>>> Thema Mobility!
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin Ibryam"<[hidden email]>:
>>>>>>>>
>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>> <[hidden email]>   wrote:
>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>
>>>>>>>>>> I like the way the design worked previously, and changing it because a user
>>>>>>>>>> might accidentally leave the comments enabled in production seems silly.
>>>>>>>>>> That is a user's QC problem, not a widget comment design problem.
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>> + 1
>>>>>>>>>
>>>>>>>>> Bilgin
>>>>
>

[Adrian Crum-3]

BJ,

The original message of this thread points out why that approach does
not work. If comments are defaulted to on, then there MUST be a way to
turn them off for things like CSV output.

-Adrian

On 9/19/2011 4:39 PM, BJ Freeman wrote:

> +1
> KISS
> one place to turn off and on. common sense says you use for development
> then you turn it off so there are no comments in the ouput.
> So there is not need to have the comments turned off at component level.
>
>
> Hans Bakker sent the following on 9/19/2011 2:14 AM:
>> If i use the widget comments option i want it to be generally applied
>> and taken away depending on the properties setting. I do not want to
>> find out that somewhere it is not following the setting, then have to
>> dig in the code and find out that is, because somebody put an
>> undocumented override somewhere by default as happened the first time.
>> Bird and google checkout is fine.
>>
>> I think how it is implemented now is fine. I hope i commented now
>> enough?
>>
>> Regards,
>> Hans
>>
>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>> Hans,
>>>
>>> Jacques gave some examples of where an override is currently used and
>>> why it is needed. Could you give us another reason besides "i think an
>>> override is an overkill" - like a reason based on a design issue or a
>>> real-world problem?
>>>
>>> -Adrian
>>>
>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>> I as sorry i do not see the problem here.....
>>>>
>>>> as long as the properties setting in the trunk will show or hide all
>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>
>>>> why? because i think an override is an overkill anyway....
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>>
>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>> Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that
>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example
>>>>> in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason..
>>>>>
>>>>> In other word I guess Hans expect widget.verbose in the properties file to be false...
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>
>>>>>> If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are
>>>>>> shut off.
>>>>>>
>>>>>> If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but
>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>
>>>>>> Will that work for everyone?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
>>>>>>> I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of
>>>>>>> always rendering as html comments.
>>>>>>> As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always used
>>>>>>> this feature in a very rough way (enable all or disable all); however I can understand the we may want to avoid that (when
>>>>>>> widget.properties.enableBoundaryComments == false) the comments are enabled by passing a URL parameter to the screen.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>
>>>>>>>> Someone I work with suggested:
>>>>>>>>
>>>>>>>> I have to point out though that I kind of agree with the way David put it in that the "false" setting could have a priority,
>>>>>>>> i.e. it's like in security permissions where "deny" has precedence over allow, so if you set it in widget.properties to false
>>>>>>>> then you're sure comments will never be enabled anywhere... security-wise it makes sense despite the comment about qc...
>>>>>>>>
>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>
>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>          || web.xml.enableBoundaryComments == false
>>>>>>>>          || context.enableBoundaryComments == false) {
>>>>>>>>      return false;
>>>>>>>> } else { // This is the solution Scott wrote, but use overriding settings only for null and true values
>>>>>>>>      if (context.enableBoundaryComments != null) return context.enableBoundaryComments;
>>>>>>>>      if (web.xml.enableBoundaryComments != null) return web.xml.enableBoundaryComments;
>>>>>>>>      if (widget.properties.enableBoundaryComments != null) return widget.properties.enableBoundaryComments;
>>>>>>>>      return false;
>>>>>>>> }
>>>>>>>>
>>>>>>>> Could probably rewrite that to be less redundant but you get the idea...
>>>>>>>>
>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what do you think?
>>>>>>>>
>>>>>>>> Also my colleague also wrote:
>>>>>>>> Only thing I have to add is that I didn't see anyone address the issue that HTML comments are outputted for CSV (because there's
>>>>>>>> no<csv>    element and you have to use<html>) element. No matter what widget.verbose is set to, there should never be HTmL
>>>>>>>> comments outputted for csv. so this only addresses half the bugs...
>>>>>>>>
>>>>>>>> We have no patches so far...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dimitri Unruh
>>>>>>>>> Consultant AEW
>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>> 33615 Bielefeld
>>>>>>>>> Deutschland
>>>>>>>>> Fon: [phone]
>>>>>>>>> Fax: [phone]
>>>>>>>>> Mobil: [phone]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Company and Management Headquarters:
>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>
>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
>>>>>>>>>
>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven Informations- und Erfahrungsaustausch rund um das
>>>>>>>>> Thema Mobility!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin Ibryam"<[hidden email]>:
>>>>>>>>>
>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>> <[hidden email]>    wrote:
>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>
>>>>>>>>>>> I like the way the design worked previously, and changing it because a user
>>>>>>>>>>> might accidentally leave the comments enabled in production seems silly.
>>>>>>>>>>> That is a user's QC problem, not a widget comment design problem.
>>>>>>>>>>>
>>>>>>>>>>> -Adrian
>>>>>>>>>>>
>>>>>>>>>> + 1
>>>>>>>>>>
>>>>>>>>>> Bilgin

[BJ Freeman]

yes I understand. but a simple turn off all comments lets you work with
that. but if you want to see what is generating that, then turn them all on.
Like Hans said, I really don't want to have to go through code to find
where it is turned off or on.

Adrian Crum sent the following on 9/19/2011 8:56 AM:

> BJ,
>
> The original message of this thread points out why that approach does
> not work. If comments are defaulted to on, then there MUST be a way to
> turn them off for things like CSV output.
>
> -Adrian
>
> On 9/19/2011 4:39 PM, BJ Freeman wrote:
>> +1
>> KISS
>> one place to turn off and on. common sense says you use for development
>> then you turn it off so there are no comments in the ouput.
>> So there is not need to have the comments turned off at component level.
>>
>>
>> Hans Bakker sent the following on 9/19/2011 2:14 AM:
>>> If i use the widget comments option i want it to be generally applied
>>> and taken away depending on the properties setting. I do not want to
>>> find out that somewhere it is not following the setting, then have to
>>> dig in the code and find out that is, because somebody put an
>>> undocumented override somewhere by default as happened the first time.
>>> Bird and google checkout is fine.
>>>
>>> I think how it is implemented now is fine. I hope i commented now
>>> enough?
>>>
>>> Regards,
>>> Hans
>>>
>>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>>> Hans,
>>>>
>>>> Jacques gave some examples of where an override is currently used and
>>>> why it is needed. Could you give us another reason besides "i think an
>>>> override is an overkill" - like a reason based on a design issue or a
>>>> real-world problem?
>>>>
>>>> -Adrian
>>>>
>>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>>> I as sorry i do not see the problem here.....
>>>>>
>>>>> as long as the properties setting in the trunk will show or hide all
>>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>>
>>>>> why? because i think an override is an overkill anyway....
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>>
>>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>>> Yes, but I guess we will set widget.verbose in the properties file
>>>>>> to true (as we do for all defaults to be dev friendly). Will that
>>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
>>>>>> For instance what for Birt by defaut? Why not keeping the example
>>>>>> in example component commented out? Waht for testtools? Not sure
>>>>>> why it's false in googlecheckout but I guess there is a reason..
>>>>>>
>>>>>> In other word I guess Hans expect widget.verbose in the properties
>>>>>> file to be false...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>>
>>>>>>> If the widget.verbose setting in the properties file is false,
>>>>>>> then it overrides any other setting and all boundary comments are
>>>>>>> shut off.
>>>>>>>
>>>>>>> If the widget.verbose setting in the properties file is true,
>>>>>>> then it follows the previous pattern, where true is the default, but
>>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>>
>>>>>>> Will that work for everyone?
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
>>>>>>>> I agree with Jacques that the formatting of boundary comments
>>>>>>>> should be output specific (i.e no output for CSV etc...) instead of
>>>>>>>> always rendering as html comments.
>>>>>>>> As regards the logic to determine if comments should be enabled
>>>>>>>> or not, I don't have a strong opinion because I have always used
>>>>>>>> this feature in a very rough way (enable all or disable all);
>>>>>>>> however I can understand the we may want to avoid that (when
>>>>>>>> widget.properties.enableBoundaryComments == false) the comments
>>>>>>>> are enabled by passing a URL parameter to the screen.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>>
>>>>>>>>> Someone I work with suggested:
>>>>>>>>>
>>>>>>>>> I have to point out though that I kind of agree with the way
>>>>>>>>> David put it in that the "false" setting could have a priority,
>>>>>>>>> i.e. it's like in security permissions where "deny" has
>>>>>>>>> precedence over allow, so if you set it in widget.properties to
>>>>>>>>> false
>>>>>>>>> then you're sure comments will never be enabled anywhere...
>>>>>>>>> security-wise it makes sense despite the comment about qc...
>>>>>>>>>
>>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>>
>>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>>          || web.xml.enableBoundaryComments == false
>>>>>>>>>          || context.enableBoundaryComments == false) {
>>>>>>>>>      return false;
>>>>>>>>> } else { // This is the solution Scott wrote, but use
>>>>>>>>> overriding settings only for null and true values
>>>>>>>>>      if (context.enableBoundaryComments != null) return
>>>>>>>>> context.enableBoundaryComments;
>>>>>>>>>      if (web.xml.enableBoundaryComments != null) return
>>>>>>>>> web.xml.enableBoundaryComments;
>>>>>>>>>      if (widget.properties.enableBoundaryComments != null)
>>>>>>>>> return widget.properties.enableBoundaryComments;
>>>>>>>>>      return false;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Could probably rewrite that to be less redundant but you get
>>>>>>>>> the idea...
>>>>>>>>>
>>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
>>>>>>>>> idea to me, what do you think?
>>>>>>>>>
>>>>>>>>> Also my colleague also wrote:
>>>>>>>>> Only thing I have to add is that I didn't see anyone address
>>>>>>>>> the issue that HTML comments are outputted for CSV (because
>>>>>>>>> there's
>>>>>>>>> no<csv>    element and you have to use<html>) element. No
>>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
>>>>>>>>> comments outputted for csv. so this only addresses half the
>>>>>>>>> bugs...
>>>>>>>>>
>>>>>>>>> We have no patches so far...
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Dimitri Unruh
>>>>>>>>>> Consultant AEW
>>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>>> 33615 Bielefeld
>>>>>>>>>> Deutschland
>>>>>>>>>> Fon: [phone]
>>>>>>>>>> Fax: [phone]
>>>>>>>>>> Mobil: [phone]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Company and Management Headquarters:
>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>>> Deutschland
>>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>>
>>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
>>>>>>>>>> 2 Stand B01
>>>>>>>>>>
>>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
>>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
>>>>>>>>>> das
>>>>>>>>>> Thema Mobility!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
>>>>>>>>>> Ibryam"<[hidden email]>:
>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>>> <[hidden email]>    wrote:
>>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>>
>>>>>>>>>>>> I like the way the design worked previously, and changing it
>>>>>>>>>>>> because a user
>>>>>>>>>>>> might accidentally leave the comments enabled in production
>>>>>>>>>>>> seems silly.
>>>>>>>>>>>> That is a user's QC problem, not a widget comment design
>>>>>>>>>>>> problem.
>>>>>>>>>>>>
>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>
>>>>>>>>>>> + 1
>>>>>>>>>>>
>>>>>>>>>>> Bilgin
>

[Adrian Crum-3]

And there are others who don't like the all-or-nothing approach. Please,
unless you have something new to add, can we stop talking in circles?

-Adrian

On 9/19/2011 5:02 PM, BJ Freeman wrote:

> yes I understand. but a simple turn off all comments lets you work with
> that. but if you want to see what is generating that, then turn them all on.
> Like Hans said, I really don't want to have to go through code to find
> where it is turned off or on.
>
> Adrian Crum sent the following on 9/19/2011 8:56 AM:
>> BJ,
>>
>> The original message of this thread points out why that approach does
>> not work. If comments are defaulted to on, then there MUST be a way to
>> turn them off for things like CSV output.
>>
>> -Adrian
>>
>> On 9/19/2011 4:39 PM, BJ Freeman wrote:
>>> +1
>>> KISS
>>> one place to turn off and on. common sense says you use for development
>>> then you turn it off so there are no comments in the ouput.
>>> So there is not need to have the comments turned off at component level.
>>>
>>>
>>> Hans Bakker sent the following on 9/19/2011 2:14 AM:
>>>> If i use the widget comments option i want it to be generally applied
>>>> and taken away depending on the properties setting. I do not want to
>>>> find out that somewhere it is not following the setting, then have to
>>>> dig in the code and find out that is, because somebody put an
>>>> undocumented override somewhere by default as happened the first time.
>>>> Bird and google checkout is fine.
>>>>
>>>> I think how it is implemented now is fine. I hope i commented now
>>>> enough?
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>>>> Hans,
>>>>>
>>>>> Jacques gave some examples of where an override is currently used and
>>>>> why it is needed. Could you give us another reason besides "i think an
>>>>> override is an overkill" - like a reason based on a design issue or a
>>>>> real-world problem?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>>>> I as sorry i do not see the problem here.....
>>>>>>
>>>>>> as long as the properties setting in the trunk will show or hide all
>>>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>>>
>>>>>> why? because i think an override is an overkill anyway....
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>>>> Yes, but I guess we will set widget.verbose in the properties file
>>>>>>> to true (as we do for all defaults to be dev friendly). Will that
>>>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
>>>>>>> For instance what for Birt by defaut? Why not keeping the example
>>>>>>> in example component commented out? Waht for testtools? Not sure
>>>>>>> why it's false in googlecheckout but I guess there is a reason..
>>>>>>>
>>>>>>> In other word I guess Hans expect widget.verbose in the properties
>>>>>>> file to be false...
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>>>
>>>>>>>> If the widget.verbose setting in the properties file is false,
>>>>>>>> then it overrides any other setting and all boundary comments are
>>>>>>>> shut off.
>>>>>>>>
>>>>>>>> If the widget.verbose setting in the properties file is true,
>>>>>>>> then it follows the previous pattern, where true is the default, but
>>>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>>>
>>>>>>>> Will that work for everyone?
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
>>>>>>>>> I agree with Jacques that the formatting of boundary comments
>>>>>>>>> should be output specific (i.e no output for CSV etc...) instead of
>>>>>>>>> always rendering as html comments.
>>>>>>>>> As regards the logic to determine if comments should be enabled
>>>>>>>>> or not, I don't have a strong opinion because I have always used
>>>>>>>>> this feature in a very rough way (enable all or disable all);
>>>>>>>>> however I can understand the we may want to avoid that (when
>>>>>>>>> widget.properties.enableBoundaryComments == false) the comments
>>>>>>>>> are enabled by passing a URL parameter to the screen.
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>>>
>>>>>>>>>> Someone I work with suggested:
>>>>>>>>>>
>>>>>>>>>> I have to point out though that I kind of agree with the way
>>>>>>>>>> David put it in that the "false" setting could have a priority,
>>>>>>>>>> i.e. it's like in security permissions where "deny" has
>>>>>>>>>> precedence over allow, so if you set it in widget.properties to
>>>>>>>>>> false
>>>>>>>>>> then you're sure comments will never be enabled anywhere...
>>>>>>>>>> security-wise it makes sense despite the comment about qc...
>>>>>>>>>>
>>>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>>>
>>>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>>>           || web.xml.enableBoundaryComments == false
>>>>>>>>>>           || context.enableBoundaryComments == false) {
>>>>>>>>>>       return false;
>>>>>>>>>> } else { // This is the solution Scott wrote, but use
>>>>>>>>>> overriding settings only for null and true values
>>>>>>>>>>       if (context.enableBoundaryComments != null) return
>>>>>>>>>> context.enableBoundaryComments;
>>>>>>>>>>       if (web.xml.enableBoundaryComments != null) return
>>>>>>>>>> web.xml.enableBoundaryComments;
>>>>>>>>>>       if (widget.properties.enableBoundaryComments != null)
>>>>>>>>>> return widget.properties.enableBoundaryComments;
>>>>>>>>>>       return false;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Could probably rewrite that to be less redundant but you get
>>>>>>>>>> the idea...
>>>>>>>>>>
>>>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
>>>>>>>>>> idea to me, what do you think?
>>>>>>>>>>
>>>>>>>>>> Also my colleague also wrote:
>>>>>>>>>> Only thing I have to add is that I didn't see anyone address
>>>>>>>>>> the issue that HTML comments are outputted for CSV (because
>>>>>>>>>> there's
>>>>>>>>>> no<csv>     element and you have to use<html>) element. No
>>>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
>>>>>>>>>> comments outputted for csv. so this only addresses half the
>>>>>>>>>> bugs...
>>>>>>>>>>
>>>>>>>>>> We have no patches so far...
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Dimitri Unruh
>>>>>>>>>>> Consultant AEW
>>>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>>>> 33615 Bielefeld
>>>>>>>>>>> Deutschland
>>>>>>>>>>> Fon: [phone]
>>>>>>>>>>> Fax: [phone]
>>>>>>>>>>> Mobil: [phone]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Company and Management Headquarters:
>>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>>>> Deutschland
>>>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>>>
>>>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
>>>>>>>>>>> 2 Stand B01
>>>>>>>>>>>
>>>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
>>>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
>>>>>>>>>>> das
>>>>>>>>>>> Thema Mobility!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
>>>>>>>>>>> Ibryam"<[hidden email]>:
>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>>>> <[hidden email]>     wrote:
>>>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I like the way the design worked previously, and changing it
>>>>>>>>>>>>> because a user
>>>>>>>>>>>>> might accidentally leave the comments enabled in production
>>>>>>>>>>>>> seems silly.
>>>>>>>>>>>>> That is a user's QC problem, not a widget comment design
>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>
>>>>>>>>>>>> + 1
>>>>>>>>>>>>
>>>>>>>>>>>> Bilgin

[BJ Freeman]

Then I suggest a vote, though mine is none binding.

Adrian Crum sent the following on 9/19/2011 9:06 AM:

> And there are others who don't like the all-or-nothing approach. Please,
> unless you have something new to add, can we stop talking in circles?
>
> -Adrian
>
> On 9/19/2011 5:02 PM, BJ Freeman wrote:
>> yes I understand. but a simple turn off all comments lets you work with
>> that. but if you want to see what is generating that, then turn them
>> all on.
>> Like Hans said, I really don't want to have to go through code to find
>> where it is turned off or on.
>>
>> Adrian Crum sent the following on 9/19/2011 8:56 AM:
>>> BJ,
>>>
>>> The original message of this thread points out why that approach does
>>> not work. If comments are defaulted to on, then there MUST be a way to
>>> turn them off for things like CSV output.
>>>
>>> -Adrian
>>>
>>> On 9/19/2011 4:39 PM, BJ Freeman wrote:
>>>> +1
>>>> KISS
>>>> one place to turn off and on. common sense says you use for development
>>>> then you turn it off so there are no comments in the ouput.
>>>> So there is not need to have the comments turned off at component
>>>> level.
>>>>
>>>>
>>>> Hans Bakker sent the following on 9/19/2011 2:14 AM:
>>>>> If i use the widget comments option i want it to be generally applied
>>>>> and taken away depending on the properties setting. I do not want to
>>>>> find out that somewhere it is not following the setting, then have to
>>>>> dig in the code and find out that is, because somebody put an
>>>>> undocumented override somewhere by default as happened the first time.
>>>>> Bird and google checkout is fine.
>>>>>
>>>>> I think how it is implemented now is fine. I hope i commented now
>>>>> enough?
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>>>>> Hans,
>>>>>>
>>>>>> Jacques gave some examples of where an override is currently used and
>>>>>> why it is needed. Could you give us another reason besides "i
>>>>>> think an
>>>>>> override is an overkill" - like a reason based on a design issue or a
>>>>>> real-world problem?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>>>>> I as sorry i do not see the problem here.....
>>>>>>>
>>>>>>> as long as the properties setting in the trunk will show or hide all
>>>>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>>>>
>>>>>>> why? because i think an override is an overkill anyway....
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>>>>> Yes, but I guess we will set widget.verbose in the properties file
>>>>>>>> to true (as we do for all defaults to be dev friendly). Will that
>>>>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
>>>>>>>> For instance what for Birt by defaut? Why not keeping the example
>>>>>>>> in example component commented out? Waht for testtools? Not sure
>>>>>>>> why it's false in googlecheckout but I guess there is a reason..
>>>>>>>>
>>>>>>>> In other word I guess Hans expect widget.verbose in the properties
>>>>>>>> file to be false...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>>>>
>>>>>>>>> If the widget.verbose setting in the properties file is false,
>>>>>>>>> then it overrides any other setting and all boundary comments are
>>>>>>>>> shut off.
>>>>>>>>>
>>>>>>>>> If the widget.verbose setting in the properties file is true,
>>>>>>>>> then it follows the previous pattern, where true is the
>>>>>>>>> default, but
>>>>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>>>>
>>>>>>>>> Will that work for everyone?
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>>>>> I am going to feel bad if I don't add my 2 cents to this
>>>>>>>>>> thread :-)
>>>>>>>>>> I agree with Jacques that the formatting of boundary comments
>>>>>>>>>> should be output specific (i.e no output for CSV etc...)
>>>>>>>>>> instead of
>>>>>>>>>> always rendering as html comments.
>>>>>>>>>> As regards the logic to determine if comments should be enabled
>>>>>>>>>> or not, I don't have a strong opinion because I have always used
>>>>>>>>>> this feature in a very rough way (enable all or disable all);
>>>>>>>>>> however I can understand the we may want to avoid that (when
>>>>>>>>>> widget.properties.enableBoundaryComments == false) the comments
>>>>>>>>>> are enabled by passing a URL parameter to the screen.
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>>>>
>>>>>>>>>>> Someone I work with suggested:
>>>>>>>>>>>
>>>>>>>>>>> I have to point out though that I kind of agree with the way
>>>>>>>>>>> David put it in that the "false" setting could have a priority,
>>>>>>>>>>> i.e. it's like in security permissions where "deny" has
>>>>>>>>>>> precedence over allow, so if you set it in widget.properties to
>>>>>>>>>>> false
>>>>>>>>>>> then you're sure comments will never be enabled anywhere...
>>>>>>>>>>> security-wise it makes sense despite the comment about qc...
>>>>>>>>>>>
>>>>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>>>>
>>>>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>>>>           || web.xml.enableBoundaryComments == false
>>>>>>>>>>>           || context.enableBoundaryComments == false) {
>>>>>>>>>>>       return false;
>>>>>>>>>>> } else { // This is the solution Scott wrote, but use
>>>>>>>>>>> overriding settings only for null and true values
>>>>>>>>>>>       if (context.enableBoundaryComments != null) return
>>>>>>>>>>> context.enableBoundaryComments;
>>>>>>>>>>>       if (web.xml.enableBoundaryComments != null) return
>>>>>>>>>>> web.xml.enableBoundaryComments;
>>>>>>>>>>>       if (widget.properties.enableBoundaryComments != null)
>>>>>>>>>>> return widget.properties.enableBoundaryComments;
>>>>>>>>>>>       return false;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Could probably rewrite that to be less redundant but you get
>>>>>>>>>>> the idea...
>>>>>>>>>>>
>>>>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
>>>>>>>>>>> idea to me, what do you think?
>>>>>>>>>>>
>>>>>>>>>>> Also my colleague also wrote:
>>>>>>>>>>> Only thing I have to add is that I didn't see anyone address
>>>>>>>>>>> the issue that HTML comments are outputted for CSV (because
>>>>>>>>>>> there's
>>>>>>>>>>> no<csv>     element and you have to use<html>) element. No
>>>>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
>>>>>>>>>>> comments outputted for csv. so this only addresses half the
>>>>>>>>>>> bugs...
>>>>>>>>>>>
>>>>>>>>>>> We have no patches so far...
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>>>>> +1
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Dimitri Unruh
>>>>>>>>>>>> Consultant AEW
>>>>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>>>>> 33615 Bielefeld
>>>>>>>>>>>> Deutschland
>>>>>>>>>>>> Fon: [phone]
>>>>>>>>>>>> Fax: [phone]
>>>>>>>>>>>> Mobil: [phone]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Company and Management Headquarters:
>>>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>>>>> Deutschland
>>>>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>>>>
>>>>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
>>>>>>>>>>>> 2 Stand B01
>>>>>>>>>>>>
>>>>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
>>>>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
>>>>>>>>>>>> das
>>>>>>>>>>>> Thema Mobility!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
>>>>>>>>>>>> Ibryam"<[hidden email]>:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>>>>> <[hidden email]>     wrote:
>>>>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I like the way the design worked previously, and changing it
>>>>>>>>>>>>>> because a user
>>>>>>>>>>>>>> might accidentally leave the comments enabled in production
>>>>>>>>>>>>>> seems silly.
>>>>>>>>>>>>>> That is a user's QC problem, not a widget comment design
>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>
>>>>>>>>>>>>> + 1
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bilgin
>

[Anne Jessel]

If the main problem is not wanting to go through all the code to find
where the comments are on/off, perhaps a solution would be log
messages at startup saying which comments are turned on where? Then
when anyone sees/doesn't see comments they do/don't want, they can
look at the startup logs to see exactly what is on and off. And then
no one will care as strongly about the details.

I'm not familiar with this code, but I'd guess adding a logging
statement where each relevant property is loaded wouldn't be
difficult? Of course, if they are loaded lots of times all over the
place, then it isn't that simple.

In which case maybe something in webtools that reports what is on and
off and where?

Cheers,
Anne.

On 20 September 2011 02:02, BJ Freeman <[hidden email]> wrote:

> yes I understand. but a simple turn off all comments lets you work with
> that. but if you want to see what is generating that, then turn them all on.
> Like Hans said, I really don't want to have to go through code to find
> where it is turned off or on.
>
> Adrian Crum sent the following on 9/19/2011 8:56 AM:
>> BJ,
>>
>> The original message of this thread points out why that approach does
>> not work. If comments are defaulted to on, then there MUST be a way to
>> turn them off for things like CSV output.
>>
>> -Adrian
>>
>> On 9/19/2011 4:39 PM, BJ Freeman wrote:
>>> +1
>>> KISS
>>> one place to turn off and on. common sense says you use for development
>>> then you turn it off so there are no comments in the ouput.
>>> So there is not need to have the comments turned off at component level.
>>>
>>>
>>> Hans Bakker sent the following on 9/19/2011 2:14 AM:
>>>> If i use the widget comments option i want it to be generally applied
>>>> and taken away depending on the properties setting. I do not want to
>>>> find out that somewhere it is not following the setting, then have to
>>>> dig in the code and find out that is, because somebody put an
>>>> undocumented override somewhere by default as happened the first time.
>>>> Bird and google checkout is fine.
>>>>
>>>> I think how it is implemented now is fine. I hope i commented now
>>>> enough?
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>>>> Hans,
>>>>>
>>>>> Jacques gave some examples of where an override is currently used and
>>>>> why it is needed. Could you give us another reason besides "i think an
>>>>> override is an overkill" - like a reason based on a design issue or a
>>>>> real-world problem?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>>>> I as sorry i do not see the problem here.....
>>>>>>
>>>>>> as long as the properties setting in the trunk will show or hide all
>>>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>>>
>>>>>> why? because i think an override is an overkill anyway....
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>>>> Yes, but I guess we will set widget.verbose in the properties file
>>>>>>> to true (as we do for all defaults to be dev friendly). Will that
>>>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
>>>>>>> For instance what for Birt by defaut? Why not keeping the example
>>>>>>> in example component commented out? Waht for testtools? Not sure
>>>>>>> why it's false in googlecheckout but I guess there is a reason..
>>>>>>>
>>>>>>> In other word I guess Hans expect widget.verbose in the properties
>>>>>>> file to be false...
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>>>
>>>>>>>> If the widget.verbose setting in the properties file is false,
>>>>>>>> then it overrides any other setting and all boundary comments are
>>>>>>>> shut off.
>>>>>>>>
>>>>>>>> If the widget.verbose setting in the properties file is true,
>>>>>>>> then it follows the previous pattern, where true is the default, but
>>>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>>>
>>>>>>>> Will that work for everyone?
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
>>>>>>>>> I agree with Jacques that the formatting of boundary comments
>>>>>>>>> should be output specific (i.e no output for CSV etc...) instead of
>>>>>>>>> always rendering as html comments.
>>>>>>>>> As regards the logic to determine if comments should be enabled
>>>>>>>>> or not, I don't have a strong opinion because I have always used
>>>>>>>>> this feature in a very rough way (enable all or disable all);
>>>>>>>>> however I can understand the we may want to avoid that (when
>>>>>>>>> widget.properties.enableBoundaryComments == false) the comments
>>>>>>>>> are enabled by passing a URL parameter to the screen.
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>>>
>>>>>>>>>> Someone I work with suggested:
>>>>>>>>>>
>>>>>>>>>> I have to point out though that I kind of agree with the way
>>>>>>>>>> David put it in that the "false" setting could have a priority,
>>>>>>>>>> i.e. it's like in security permissions where "deny" has
>>>>>>>>>> precedence over allow, so if you set it in widget.properties to
>>>>>>>>>> false
>>>>>>>>>> then you're sure comments will never be enabled anywhere...
>>>>>>>>>> security-wise it makes sense despite the comment about qc...
>>>>>>>>>>
>>>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>>>
>>>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>>>          || web.xml.enableBoundaryComments == false
>>>>>>>>>>          || context.enableBoundaryComments == false) {
>>>>>>>>>>      return false;
>>>>>>>>>> } else { // This is the solution Scott wrote, but use
>>>>>>>>>> overriding settings only for null and true values
>>>>>>>>>>      if (context.enableBoundaryComments != null) return
>>>>>>>>>> context.enableBoundaryComments;
>>>>>>>>>>      if (web.xml.enableBoundaryComments != null) return
>>>>>>>>>> web.xml.enableBoundaryComments;
>>>>>>>>>>      if (widget.properties.enableBoundaryComments != null)
>>>>>>>>>> return widget.properties.enableBoundaryComments;
>>>>>>>>>>      return false;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Could probably rewrite that to be less redundant but you get
>>>>>>>>>> the idea...
>>>>>>>>>>
>>>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
>>>>>>>>>> idea to me, what do you think?
>>>>>>>>>>
>>>>>>>>>> Also my colleague also wrote:
>>>>>>>>>> Only thing I have to add is that I didn't see anyone address
>>>>>>>>>> the issue that HTML comments are outputted for CSV (because
>>>>>>>>>> there's
>>>>>>>>>> no<csv>    element and you have to use<html>) element. No
>>>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
>>>>>>>>>> comments outputted for csv. so this only addresses half the
>>>>>>>>>> bugs...
>>>>>>>>>>
>>>>>>>>>> We have no patches so far...
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Dimitri Unruh
>>>>>>>>>>> Consultant AEW
>>>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>>>> 33615 Bielefeld
>>>>>>>>>>> Deutschland
>>>>>>>>>>> Fon: [phone]
>>>>>>>>>>> Fax: [phone]
>>>>>>>>>>> Mobil: [phone]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Company and Management Headquarters:
>>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>>>> Deutschland
>>>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>>>
>>>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
>>>>>>>>>>> 2 Stand B01
>>>>>>>>>>>
>>>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
>>>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
>>>>>>>>>>> das
>>>>>>>>>>> Thema Mobility!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
>>>>>>>>>>> Ibryam"<[hidden email]>:
>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>>>> <[hidden email]>    wrote:
>>>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I like the way the design worked previously, and changing it
>>>>>>>>>>>>> because a user
>>>>>>>>>>>>> might accidentally leave the comments enabled in production
>>>>>>>>>>>>> seems silly.
>>>>>>>>>>>>> That is a user's QC problem, not a widget comment design
>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>
>>>>>>>>>>>> + 1
>>>>>>>>>>>>
>>>>>>>>>>>> Bilgin
>>
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[Adrian Crum-3]

Anne,

Logging the settings is not necessary because the design is not that
complicated. A setting in the widget.properties file is the default.
That setting can be overridden in web.xml, and the setting in web.xml
can be overridden in an individual screen widget by setting a value in
the rendering context. So:

properties file -> web.xml -> rendering context

There is no need to go through code. If you enabled the widget comments
in the properties file and the comments are not appearing in a
particular web application, then check the web.xml file. If the comments
are appearing in a web application but not in a particular screen, then
check the screen widget xml file. It's very simple. We just have a
couple of people who are trying to make it seem hard.

-Adrian

On 9/20/2011 12:56 AM, Anne wrote:

> If the main problem is not wanting to go through all the code to find
> where the comments are on/off, perhaps a solution would be log
> messages at startup saying which comments are turned on where? Then
> when anyone sees/doesn't see comments they do/don't want, they can
> look at the startup logs to see exactly what is on and off. And then
> no one will care as strongly about the details.
>
> I'm not familiar with this code, but I'd guess adding a logging
> statement where each relevant property is loaded wouldn't be
> difficult? Of course, if they are loaded lots of times all over the
> place, then it isn't that simple.
>
> In which case maybe something in webtools that reports what is on and
> off and where?
>
> Cheers,
> Anne.
>
> On 20 September 2011 02:02, BJ Freeman<[hidden email]>  wrote:
>> yes I understand. but a simple turn off all comments lets you work with
>> that. but if you want to see what is generating that, then turn them all on.
>> Like Hans said, I really don't want to have to go through code to find
>> where it is turned off or on.
>>
>> Adrian Crum sent the following on 9/19/2011 8:56 AM:
>>> BJ,
>>>
>>> The original message of this thread points out why that approach does
>>> not work. If comments are defaulted to on, then there MUST be a way to
>>> turn them off for things like CSV output.
>>>
>>> -Adrian
>>>
>>> On 9/19/2011 4:39 PM, BJ Freeman wrote:
>>>> +1
>>>> KISS
>>>> one place to turn off and on. common sense says you use for development
>>>> then you turn it off so there are no comments in the ouput.
>>>> So there is not need to have the comments turned off at component level.
>>>>
>>>>
>>>> Hans Bakker sent the following on 9/19/2011 2:14 AM:
>>>>> If i use the widget comments option i want it to be generally applied
>>>>> and taken away depending on the properties setting. I do not want to
>>>>> find out that somewhere it is not following the setting, then have to
>>>>> dig in the code and find out that is, because somebody put an
>>>>> undocumented override somewhere by default as happened the first time.
>>>>> Bird and google checkout is fine.
>>>>>
>>>>> I think how it is implemented now is fine. I hope i commented now
>>>>> enough?
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>>>>> Hans,
>>>>>>
>>>>>> Jacques gave some examples of where an override is currently used and
>>>>>> why it is needed. Could you give us another reason besides "i think an
>>>>>> override is an overkill" - like a reason based on a design issue or a
>>>>>> real-world problem?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>>>>> I as sorry i do not see the problem here.....
>>>>>>>
>>>>>>> as long as the properties setting in the trunk will show or hide all
>>>>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>>>>
>>>>>>> why? because i think an override is an overkill anyway....
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>>>>> Yes, but I guess we will set widget.verbose in the properties file
>>>>>>>> to true (as we do for all defaults to be dev friendly). Will that
>>>>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
>>>>>>>> For instance what for Birt by defaut? Why not keeping the example
>>>>>>>> in example component commented out? Waht for testtools? Not sure
>>>>>>>> why it's false in googlecheckout but I guess there is a reason..
>>>>>>>>
>>>>>>>> In other word I guess Hans expect widget.verbose in the properties
>>>>>>>> file to be false...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>>>>
>>>>>>>>> If the widget.verbose setting in the properties file is false,
>>>>>>>>> then it overrides any other setting and all boundary comments are
>>>>>>>>> shut off.
>>>>>>>>>
>>>>>>>>> If the widget.verbose setting in the properties file is true,
>>>>>>>>> then it follows the previous pattern, where true is the default, but
>>>>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>>>>
>>>>>>>>> Will that work for everyone?
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
>>>>>>>>>> I agree with Jacques that the formatting of boundary comments
>>>>>>>>>> should be output specific (i.e no output for CSV etc...) instead of
>>>>>>>>>> always rendering as html comments.
>>>>>>>>>> As regards the logic to determine if comments should be enabled
>>>>>>>>>> or not, I don't have a strong opinion because I have always used
>>>>>>>>>> this feature in a very rough way (enable all or disable all);
>>>>>>>>>> however I can understand the we may want to avoid that (when
>>>>>>>>>> widget.properties.enableBoundaryComments == false) the comments
>>>>>>>>>> are enabled by passing a URL parameter to the screen.
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>>>>
>>>>>>>>>>> Someone I work with suggested:
>>>>>>>>>>>
>>>>>>>>>>> I have to point out though that I kind of agree with the way
>>>>>>>>>>> David put it in that the "false" setting could have a priority,
>>>>>>>>>>> i.e. it's like in security permissions where "deny" has
>>>>>>>>>>> precedence over allow, so if you set it in widget.properties to
>>>>>>>>>>> false
>>>>>>>>>>> then you're sure comments will never be enabled anywhere...
>>>>>>>>>>> security-wise it makes sense despite the comment about qc...
>>>>>>>>>>>
>>>>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>>>>
>>>>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>>>>           || web.xml.enableBoundaryComments == false
>>>>>>>>>>>           || context.enableBoundaryComments == false) {
>>>>>>>>>>>       return false;
>>>>>>>>>>> } else { // This is the solution Scott wrote, but use
>>>>>>>>>>> overriding settings only for null and true values
>>>>>>>>>>>       if (context.enableBoundaryComments != null) return
>>>>>>>>>>> context.enableBoundaryComments;
>>>>>>>>>>>       if (web.xml.enableBoundaryComments != null) return
>>>>>>>>>>> web.xml.enableBoundaryComments;
>>>>>>>>>>>       if (widget.properties.enableBoundaryComments != null)
>>>>>>>>>>> return widget.properties.enableBoundaryComments;
>>>>>>>>>>>       return false;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Could probably rewrite that to be less redundant but you get
>>>>>>>>>>> the idea...
>>>>>>>>>>>
>>>>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
>>>>>>>>>>> idea to me, what do you think?
>>>>>>>>>>>
>>>>>>>>>>> Also my colleague also wrote:
>>>>>>>>>>> Only thing I have to add is that I didn't see anyone address
>>>>>>>>>>> the issue that HTML comments are outputted for CSV (because
>>>>>>>>>>> there's
>>>>>>>>>>> no<csv>      element and you have to use<html>) element. No
>>>>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
>>>>>>>>>>> comments outputted for csv. so this only addresses half the
>>>>>>>>>>> bugs...
>>>>>>>>>>>
>>>>>>>>>>> We have no patches so far...
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>>>>> +1
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Dimitri Unruh
>>>>>>>>>>>> Consultant AEW
>>>>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>>>>> 33615 Bielefeld
>>>>>>>>>>>> Deutschland
>>>>>>>>>>>> Fon: [phone]
>>>>>>>>>>>> Fax: [phone]
>>>>>>>>>>>> Mobil: [phone]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Company and Management Headquarters:
>>>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>>>>> Deutschland
>>>>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>>>>
>>>>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
>>>>>>>>>>>> 2 Stand B01
>>>>>>>>>>>>
>>>>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
>>>>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
>>>>>>>>>>>> das
>>>>>>>>>>>> Thema Mobility!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
>>>>>>>>>>>> Ibryam"<[hidden email]>:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>>>>> <[hidden email]>      wrote:
>>>>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I like the way the design worked previously, and changing it
>>>>>>>>>>>>>> because a user
>>>>>>>>>>>>>> might accidentally leave the comments enabled in production
>>>>>>>>>>>>>> seems silly.
>>>>>>>>>>>>>> That is a user's QC problem, not a widget comment design
>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>
>>>>>>>>>>>>> + 1
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bilgin
>
>

[Anne Jessel]

Thanks Adrian. I was just trying to work out a way everyone would get
what they really wanted.

Your precedence makes sense to me, and I'm not sure I understand
others' concerns. But that doesn't mean I think they are unimportant,
just that I haven't managed to understand yet.

I was thinking their concern was that it was difficult to determine
what's on/off and where, and hence thought I'd suggest a possible
solution to that problem. Maybe I'm wrong.

Cheers,
Anne.

On 20 September 2011 10:06, Adrian Crum
<[hidden email]> wrote:

> Anne,
>
> Logging the settings is not necessary because the design is not that
> complicated. A setting in the widget.properties file is the default. That
> setting can be overridden in web.xml, and the setting in web.xml can be
> overridden in an individual screen widget by setting a value in the
> rendering context. So:
>
> properties file -> web.xml -> rendering context
>
> There is no need to go through code. If you enabled the widget comments in
> the properties file and the comments are not appearing in a particular web
> application, then check the web.xml file. If the comments are appearing in a
> web application but not in a particular screen, then check the screen widget
> xml file. It's very simple. We just have a couple of people who are trying
> to make it seem hard.
>
> -Adrian
>
> On 9/20/2011 12:56 AM, Anne wrote:
>>
>> If the main problem is not wanting to go through all the code to find
>> where the comments are on/off, perhaps a solution would be log
>> messages at startup saying which comments are turned on where? Then
>> when anyone sees/doesn't see comments they do/don't want, they can
>> look at the startup logs to see exactly what is on and off. And then
>> no one will care as strongly about the details.
>>
>> I'm not familiar with this code, but I'd guess adding a logging
>> statement where each relevant property is loaded wouldn't be
>> difficult? Of course, if they are loaded lots of times all over the
>> place, then it isn't that simple.
>>
>> In which case maybe something in webtools that reports what is on and
>> off and where?
>>
>> Cheers,
>> Anne.
>>
>> On 20 September 2011 02:02, BJ Freeman<[hidden email]>  wrote:
>>>
>>> yes I understand. but a simple turn off all comments lets you work with
>>> that. but if you want to see what is generating that, then turn them all
>>> on.
>>> Like Hans said, I really don't want to have to go through code to find
>>> where it is turned off or on.
>>>
>>> Adrian Crum sent the following on 9/19/2011 8:56 AM:
>>>>
>>>> BJ,
>>>>
>>>> The original message of this thread points out why that approach does
>>>> not work. If comments are defaulted to on, then there MUST be a way to
>>>> turn them off for things like CSV output.
>>>>
>>>> -Adrian
>>>>
>>>> On 9/19/2011 4:39 PM, BJ Freeman wrote:
>>>>>
>>>>> +1
>>>>> KISS
>>>>> one place to turn off and on. common sense says you use for development
>>>>> then you turn it off so there are no comments in the ouput.
>>>>> So there is not need to have the comments turned off at component
>>>>> level.
>>>>>
>>>>>
>>>>> Hans Bakker sent the following on 9/19/2011 2:14 AM:
>>>>>>
>>>>>> If i use the widget comments option i want it to be generally applied
>>>>>> and taken away depending on the properties setting. I do not want to
>>>>>> find out that somewhere it is not following the setting, then have to
>>>>>> dig in the code and find out that is, because somebody put an
>>>>>> undocumented override somewhere by default as happened the first time.
>>>>>> Bird and google checkout is fine.
>>>>>>
>>>>>> I think how it is implemented now is fine. I hope i commented now
>>>>>> enough?
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>>>>>>
>>>>>>> Hans,
>>>>>>>
>>>>>>> Jacques gave some examples of where an override is currently used and
>>>>>>> why it is needed. Could you give us another reason besides "i think
>>>>>>> an
>>>>>>> override is an overkill" - like a reason based on a design issue or a
>>>>>>> real-world problem?
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>>>>>>
>>>>>>>> I as sorry i do not see the problem here.....
>>>>>>>>
>>>>>>>> as long as the properties setting in the trunk will show or hide all
>>>>>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>>>>>
>>>>>>>> why? because i think an override is an overkill anyway....
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hans
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>>>>>>
>>>>>>>>> Yes, but I guess we will set widget.verbose in the properties file
>>>>>>>>> to true (as we do for all defaults to be dev friendly). Will that
>>>>>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
>>>>>>>>> For instance what for Birt by defaut? Why not keeping the example
>>>>>>>>> in example component commented out? Waht for testtools? Not sure
>>>>>>>>> why it's false in googlecheckout but I guess there is a reason..
>>>>>>>>>
>>>>>>>>> In other word I guess Hans expect widget.verbose in the properties
>>>>>>>>> file to be false...
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>>>>>>
>>>>>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>>>>>
>>>>>>>>>> If the widget.verbose setting in the properties file is false,
>>>>>>>>>> then it overrides any other setting and all boundary comments are
>>>>>>>>>> shut off.
>>>>>>>>>>
>>>>>>>>>> If the widget.verbose setting in the properties file is true,
>>>>>>>>>> then it follows the previous pattern, where true is the default,
>>>>>>>>>> but
>>>>>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>>>>>
>>>>>>>>>> Will that work for everyone?
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>
>>>>>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread
>>>>>>>>>>> :-)
>>>>>>>>>>> I agree with Jacques that the formatting of boundary comments
>>>>>>>>>>> should be output specific (i.e no output for CSV etc...) instead
>>>>>>>>>>> of
>>>>>>>>>>> always rendering as html comments.
>>>>>>>>>>> As regards the logic to determine if comments should be enabled
>>>>>>>>>>> or not, I don't have a strong opinion because I have always used
>>>>>>>>>>> this feature in a very rough way (enable all or disable all);
>>>>>>>>>>> however I can understand the we may want to avoid that (when
>>>>>>>>>>> widget.properties.enableBoundaryComments == false) the comments
>>>>>>>>>>> are enabled by passing a URL parameter to the screen.
>>>>>>>>>>>
>>>>>>>>>>> Kind regards,
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Someone I work with suggested:
>>>>>>>>>>>>
>>>>>>>>>>>> I have to point out though that I kind of agree with the way
>>>>>>>>>>>> David put it in that the "false" setting could have a priority,
>>>>>>>>>>>> i.e. it's like in security permissions where "deny" has
>>>>>>>>>>>> precedence over allow, so if you set it in widget.properties to
>>>>>>>>>>>> false
>>>>>>>>>>>> then you're sure comments will never be enabled anywhere...
>>>>>>>>>>>> security-wise it makes sense despite the comment about qc...
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>>>>>
>>>>>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>>>>>          || web.xml.enableBoundaryComments == false
>>>>>>>>>>>>          || context.enableBoundaryComments == false) {
>>>>>>>>>>>>      return false;
>>>>>>>>>>>> } else { // This is the solution Scott wrote, but use
>>>>>>>>>>>> overriding settings only for null and true values
>>>>>>>>>>>>      if (context.enableBoundaryComments != null) return
>>>>>>>>>>>> context.enableBoundaryComments;
>>>>>>>>>>>>      if (web.xml.enableBoundaryComments != null) return
>>>>>>>>>>>> web.xml.enableBoundaryComments;
>>>>>>>>>>>>      if (widget.properties.enableBoundaryComments != null)
>>>>>>>>>>>> return widget.properties.enableBoundaryComments;
>>>>>>>>>>>>      return false;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Could probably rewrite that to be less redundant but you get
>>>>>>>>>>>> the idea...
>>>>>>>>>>>>
>>>>>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
>>>>>>>>>>>> idea to me, what do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Also my colleague also wrote:
>>>>>>>>>>>> Only thing I have to add is that I didn't see anyone address
>>>>>>>>>>>> the issue that HTML comments are outputted for CSV (because
>>>>>>>>>>>> there's
>>>>>>>>>>>> no<csv>      element and you have to use<html>) element. No
>>>>>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
>>>>>>>>>>>> comments outputted for csv. so this only addresses half the
>>>>>>>>>>>> bugs...
>>>>>>>>>>>>
>>>>>>>>>>>> We have no patches so far...
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dimitri Unruh
>>>>>>>>>>>>> Consultant AEW
>>>>>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>>>>>> 33615 Bielefeld
>>>>>>>>>>>>> Deutschland
>>>>>>>>>>>>> Fon: [phone]
>>>>>>>>>>>>> Fax: [phone]
>>>>>>>>>>>>> Mobil: [phone]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Company and Management Headquarters:
>>>>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>>>>>> Deutschland
>>>>>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>>>>>
>>>>>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
>>>>>>>>>>>>> 2 Stand B01
>>>>>>>>>>>>>
>>>>>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
>>>>>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
>>>>>>>>>>>>> das
>>>>>>>>>>>>> Thema Mobility!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
>>>>>>>>>>>>> Ibryam"<[hidden email]>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>>>>>> <[hidden email]>      wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I like the way the design worked previously, and changing it
>>>>>>>>>>>>>>> because a user
>>>>>>>>>>>>>>> might accidentally leave the comments enabled in production
>>>>>>>>>>>>>>> seems silly.
>>>>>>>>>>>>>>> That is a user's QC problem, not a widget comment design
>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> + 1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bilgin
>>
>>
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[Adrian Crum-3]

Anne,

Your suggestions are appreciated.

We're already making a mountain out of a molehill with this issue, and
logging the setting would just add to the mountain.

-Adrian

On 9/20/2011 1:29 AM, Anne wrote:

> Thanks Adrian. I was just trying to work out a way everyone would get
> what they really wanted.
>
> Your precedence makes sense to me, and I'm not sure I understand
> others' concerns. But that doesn't mean I think they are unimportant,
> just that I haven't managed to understand yet.
>
> I was thinking their concern was that it was difficult to determine
> what's on/off and where, and hence thought I'd suggest a possible
> solution to that problem. Maybe I'm wrong.
>
> Cheers,
> Anne.
>
> On 20 September 2011 10:06, Adrian Crum
> <[hidden email]>  wrote:
>> Anne,
>>
>> Logging the settings is not necessary because the design is not that
>> complicated. A setting in the widget.properties file is the default. That
>> setting can be overridden in web.xml, and the setting in web.xml can be
>> overridden in an individual screen widget by setting a value in the
>> rendering context. So:
>>
>> properties file ->  web.xml ->  rendering context
>>
>> There is no need to go through code. If you enabled the widget comments in
>> the properties file and the comments are not appearing in a particular web
>> application, then check the web.xml file. If the comments are appearing in a
>> web application but not in a particular screen, then check the screen widget
>> xml file. It's very simple. We just have a couple of people who are trying
>> to make it seem hard.
>>
>> -Adrian
>>
>> On 9/20/2011 12:56 AM, Anne wrote:
>>> If the main problem is not wanting to go through all the code to find
>>> where the comments are on/off, perhaps a solution would be log
>>> messages at startup saying which comments are turned on where? Then
>>> when anyone sees/doesn't see comments they do/don't want, they can
>>> look at the startup logs to see exactly what is on and off. And then
>>> no one will care as strongly about the details.
>>>
>>> I'm not familiar with this code, but I'd guess adding a logging
>>> statement where each relevant property is loaded wouldn't be
>>> difficult? Of course, if they are loaded lots of times all over the
>>> place, then it isn't that simple.
>>>
>>> In which case maybe something in webtools that reports what is on and
>>> off and where?
>>>
>>> Cheers,
>>> Anne.
>>>
>>> On 20 September 2011 02:02, BJ Freeman<[hidden email]>    wrote:
>>>> yes I understand. but a simple turn off all comments lets you work with
>>>> that. but if you want to see what is generating that, then turn them all
>>>> on.
>>>> Like Hans said, I really don't want to have to go through code to find
>>>> where it is turned off or on.
>>>>
>>>> Adrian Crum sent the following on 9/19/2011 8:56 AM:
>>>>> BJ,
>>>>>
>>>>> The original message of this thread points out why that approach does
>>>>> not work. If comments are defaulted to on, then there MUST be a way to
>>>>> turn them off for things like CSV output.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 9/19/2011 4:39 PM, BJ Freeman wrote:
>>>>>> +1
>>>>>> KISS
>>>>>> one place to turn off and on. common sense says you use for development
>>>>>> then you turn it off so there are no comments in the ouput.
>>>>>> So there is not need to have the comments turned off at component
>>>>>> level.
>>>>>>
>>>>>>
>>>>>> Hans Bakker sent the following on 9/19/2011 2:14 AM:
>>>>>>> If i use the widget comments option i want it to be generally applied
>>>>>>> and taken away depending on the properties setting. I do not want to
>>>>>>> find out that somewhere it is not following the setting, then have to
>>>>>>> dig in the code and find out that is, because somebody put an
>>>>>>> undocumented override somewhere by default as happened the first time.
>>>>>>> Bird and google checkout is fine.
>>>>>>>
>>>>>>> I think how it is implemented now is fine. I hope i commented now
>>>>>>> enough?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>>>>>>> Hans,
>>>>>>>>
>>>>>>>> Jacques gave some examples of where an override is currently used and
>>>>>>>> why it is needed. Could you give us another reason besides "i think
>>>>>>>> an
>>>>>>>> override is an overkill" - like a reason based on a design issue or a
>>>>>>>> real-world problem?
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>>>>>>> I as sorry i do not see the problem here.....
>>>>>>>>>
>>>>>>>>> as long as the properties setting in the trunk will show or hide all
>>>>>>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>>>>>>
>>>>>>>>> why? because i think an override is an overkill anyway....
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hans
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>>>>>>> Yes, but I guess we will set widget.verbose in the properties file
>>>>>>>>>> to true (as we do for all defaults to be dev friendly). Will that
>>>>>>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
>>>>>>>>>> For instance what for Birt by defaut? Why not keeping the example
>>>>>>>>>> in example component commented out? Waht for testtools? Not sure
>>>>>>>>>> why it's false in googlecheckout but I guess there is a reason..
>>>>>>>>>>
>>>>>>>>>> In other word I guess Hans expect widget.verbose in the properties
>>>>>>>>>> file to be false...
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>>>>>>
>>>>>>>>>>> If the widget.verbose setting in the properties file is false,
>>>>>>>>>>> then it overrides any other setting and all boundary comments are
>>>>>>>>>>> shut off.
>>>>>>>>>>>
>>>>>>>>>>> If the widget.verbose setting in the properties file is true,
>>>>>>>>>>> then it follows the previous pattern, where true is the default,
>>>>>>>>>>> but
>>>>>>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>>>>>>
>>>>>>>>>>> Will that work for everyone?
>>>>>>>>>>>
>>>>>>>>>>> -Adrian
>>>>>>>>>>>
>>>>>>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread
>>>>>>>>>>>> :-)
>>>>>>>>>>>> I agree with Jacques that the formatting of boundary comments
>>>>>>>>>>>> should be output specific (i.e no output for CSV etc...) instead
>>>>>>>>>>>> of
>>>>>>>>>>>> always rendering as html comments.
>>>>>>>>>>>> As regards the logic to determine if comments should be enabled
>>>>>>>>>>>> or not, I don't have a strong opinion because I have always used
>>>>>>>>>>>> this feature in a very rough way (enable all or disable all);
>>>>>>>>>>>> however I can understand the we may want to avoid that (when
>>>>>>>>>>>> widget.properties.enableBoundaryComments == false) the comments
>>>>>>>>>>>> are enabled by passing a URL parameter to the screen.
>>>>>>>>>>>>
>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Someone I work with suggested:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have to point out though that I kind of agree with the way
>>>>>>>>>>>>> David put it in that the "false" setting could have a priority,
>>>>>>>>>>>>> i.e. it's like in security permissions where "deny" has
>>>>>>>>>>>>> precedence over allow, so if you set it in widget.properties to
>>>>>>>>>>>>> false
>>>>>>>>>>>>> then you're sure comments will never be enabled anywhere...
>>>>>>>>>>>>> security-wise it makes sense despite the comment about qc...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>>>>>>
>>>>>>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>>>>>>           || web.xml.enableBoundaryComments == false
>>>>>>>>>>>>>           || context.enableBoundaryComments == false) {
>>>>>>>>>>>>>       return false;
>>>>>>>>>>>>> } else { // This is the solution Scott wrote, but use
>>>>>>>>>>>>> overriding settings only for null and true values
>>>>>>>>>>>>>       if (context.enableBoundaryComments != null) return
>>>>>>>>>>>>> context.enableBoundaryComments;
>>>>>>>>>>>>>       if (web.xml.enableBoundaryComments != null) return
>>>>>>>>>>>>> web.xml.enableBoundaryComments;
>>>>>>>>>>>>>       if (widget.properties.enableBoundaryComments != null)
>>>>>>>>>>>>> return widget.properties.enableBoundaryComments;
>>>>>>>>>>>>>       return false;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could probably rewrite that to be less redundant but you get
>>>>>>>>>>>>> the idea...
>>>>>>>>>>>>>
>>>>>>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
>>>>>>>>>>>>> idea to me, what do you think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also my colleague also wrote:
>>>>>>>>>>>>> Only thing I have to add is that I didn't see anyone address
>>>>>>>>>>>>> the issue that HTML comments are outputted for CSV (because
>>>>>>>>>>>>> there's
>>>>>>>>>>>>> no<csv>        element and you have to use<html>) element. No
>>>>>>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
>>>>>>>>>>>>> comments outputted for csv. so this only addresses half the
>>>>>>>>>>>>> bugs...
>>>>>>>>>>>>>
>>>>>>>>>>>>> We have no patches so far...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dimitri Unruh
>>>>>>>>>>>>>> Consultant AEW
>>>>>>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>>>>>>> 33615 Bielefeld
>>>>>>>>>>>>>> Deutschland
>>>>>>>>>>>>>> Fon: [phone]
>>>>>>>>>>>>>> Fax: [phone]
>>>>>>>>>>>>>> Mobil: [phone]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Company and Management Headquarters:
>>>>>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>>>>>>> Deutschland
>>>>>>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
>>>>>>>>>>>>>> 2 Stand B01
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
>>>>>>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
>>>>>>>>>>>>>> das
>>>>>>>>>>>>>> Thema Mobility!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
>>>>>>>>>>>>>> Ibryam"<[hidden email]>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>>>>>>> <[hidden email]>        wrote:
>>>>>>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I like the way the design worked previously, and changing it
>>>>>>>>>>>>>>>> because a user
>>>>>>>>>>>>>>>> might accidentally leave the comments enabled in production
>>>>>>>>>>>>>>>> seems silly.
>>>>>>>>>>>>>>>> That is a user's QC problem, not a widget comment design
>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> + 1
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Bilgin
>>>
>
>

[Adrian Crum-3]

Thank you everyone for your patience and comments during this
discussion. I believe we are near a resolution.

 From my perspective, this is where we stand:

1. I proposed the following design based on David's suggestion:

If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments are
shut off.

If the widget.verbose setting in the properties file is true, then it
follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.

2. Hans is willing to accept the design, as long as there are no
undocumented "surprises" where the setting is changed in web.xml files.
Some web applications that require the setting to be off even when the
default is on are okay.

3. I asked Hans for a confirmation that my understanding of his replies
is correct. He has not replied.

4. If there are no further objections, then we can proceed with
implementing the design.

-Adrian


On 9/19/2011 10:23 AM, Adrian Crum wrote:

> Hans,
>
> We can document the behavior in the properties file, and we have this
> discussion on record to describe the behavior and the reason why it
> was done that way. I believe those things will help avoid confusion in
> the future.
>
> So, can we implement the behavior I described? I believe you already
> answered this question, but I am asking again just to be sure.
>
> -Adrian
>
> On 9/19/2011 10:14 AM, Hans Bakker wrote:
>> If i use the widget comments option i want it to be generally applied
>> and taken away depending on the properties setting. I do not want to
>> find out that somewhere it is not following the setting, then have to
>> dig in the code and find out that is, because somebody put an
>> undocumented override somewhere by default as happened the first time.
>> Bird and google checkout is fine.
>>
>> I think how it is implemented now is fine. I hope i commented now
>> enough?
>>
>> Regards,
>> Hans
>>
>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>> Hans,
>>>
>>> Jacques gave some examples of where an override is currently used and
>>> why it is needed. Could you give us another reason besides "i think an
>>> override is an overkill" - like a reason based on a design issue or a
>>> real-world problem?
>>>
>>> -Adrian
>>>
>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>> I as sorry i do not see the problem here.....
>>>>
>>>> as long as the properties setting in the trunk will show or hide all
>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>
>>>> why? because i think an override is an overkill anyway....
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>>
>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>> Yes, but I guess we will set widget.verbose in the properties file
>>>>> to true (as we do for all defaults to be dev friendly). Will that
>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
>>>>> For instance what for Birt by defaut? Why not keeping the example
>>>>> in example component commented out? Waht for testtools? Not sure
>>>>> why it's false in googlecheckout but I guess there is a reason..
>>>>>
>>>>> In other word I guess Hans expect widget.verbose in the properties
>>>>> file to be false...
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>
>>>>>> If the widget.verbose setting in the properties file is false,
>>>>>> then it overrides any other setting and all boundary comments are
>>>>>> shut off.
>>>>>>
>>>>>> If the widget.verbose setting in the properties file is true,
>>>>>> then it follows the previous pattern, where true is the default, but
>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>
>>>>>> Will that work for everyone?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
>>>>>>> I agree with Jacques that the formatting of boundary comments
>>>>>>> should be output specific (i.e no output for CSV etc...) instead of
>>>>>>> always rendering as html comments.
>>>>>>> As regards the logic to determine if comments should be enabled
>>>>>>> or not, I don't have a strong opinion because I have always used
>>>>>>> this feature in a very rough way (enable all or disable all);
>>>>>>> however I can understand the we may want to avoid that (when
>>>>>>> widget.properties.enableBoundaryComments == false) the comments
>>>>>>> are enabled by passing a URL parameter to the screen.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>
>>>>>>>> Someone I work with suggested:
>>>>>>>>
>>>>>>>> I have to point out though that I kind of agree with the way
>>>>>>>> David put it in that the "false" setting could have a priority,
>>>>>>>> i.e. it's like in security permissions where "deny" has
>>>>>>>> precedence over allow, so if you set it in widget.properties to
>>>>>>>> false
>>>>>>>> then you're sure comments will never be enabled anywhere...
>>>>>>>> security-wise it makes sense despite the comment about qc...
>>>>>>>>
>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>
>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>          || web.xml.enableBoundaryComments == false
>>>>>>>>          || context.enableBoundaryComments == false) {
>>>>>>>>      return false;
>>>>>>>> } else { // This is the solution Scott wrote, but use
>>>>>>>> overriding settings only for null and true values
>>>>>>>>      if (context.enableBoundaryComments != null) return
>>>>>>>> context.enableBoundaryComments;
>>>>>>>>      if (web.xml.enableBoundaryComments != null) return
>>>>>>>> web.xml.enableBoundaryComments;
>>>>>>>>      if (widget.properties.enableBoundaryComments != null)
>>>>>>>> return widget.properties.enableBoundaryComments;
>>>>>>>>      return false;
>>>>>>>> }
>>>>>>>>
>>>>>>>> Could probably rewrite that to be less redundant but you get
>>>>>>>> the idea...
>>>>>>>>
>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
>>>>>>>> idea to me, what do you think?
>>>>>>>>
>>>>>>>> Also my colleague also wrote:
>>>>>>>> Only thing I have to add is that I didn't see anyone address
>>>>>>>> the issue that HTML comments are outputted for CSV (because
>>>>>>>> there's
>>>>>>>> no<csv>    element and you have to use<html>) element. No
>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
>>>>>>>> comments outputted for csv. so this only addresses half the
>>>>>>>> bugs...
>>>>>>>>
>>>>>>>> We have no patches so far...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dimitri Unruh
>>>>>>>>> Consultant AEW
>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>> 33615 Bielefeld
>>>>>>>>> Deutschland
>>>>>>>>> Fon: [phone]
>>>>>>>>> Fax: [phone]
>>>>>>>>> Mobil: [phone]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Company and Management Headquarters:
>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>> Deutschland
>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>
>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
>>>>>>>>> 2 Stand B01
>>>>>>>>>
>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
>>>>>>>>> das
>>>>>>>>> Thema Mobility!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
>>>>>>>>> Ibryam"<[hidden email]>:
>>>>>>>>>
>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>> <[hidden email]>    wrote:
>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>
>>>>>>>>>>> I like the way the design worked previously, and changing it
>>>>>>>>>>> because a user
>>>>>>>>>>> might accidentally leave the comments enabled in production
>>>>>>>>>>> seems silly.
>>>>>>>>>>> That is a user's QC problem, not a widget comment design
>>>>>>>>>>> problem.
>>>>>>>>>>>
>>>>>>>>>>> -Adrian
>>>>>>>>>>>
>>>>>>>>>> + 1
>>>>>>>>>>
>>>>>>>>>> Bilgin

[hans_bakker]

Ok Adrian, at least for the third time: (five times in a different
wording)

what i wrote?

> as long as the properties setting in the trunk will show or hide all
> widget comments (so in the trunk NO override) then it is fine.

Regards,
Hans


On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote:

> Thank you everyone for your patience and comments during this
> discussion. I believe we are near a resolution.
>
>  From my perspective, this is where we stand:
>
> 1. I proposed the following design based on David's suggestion:
>
> If the widget.verbose setting in the properties file is false, then it
> overrides any other setting and all boundary comments are
> shut off.
>
> If the widget.verbose setting in the properties file is true, then it
> follows the previous pattern, where true is the default, but
> it can be overridden in web.xml and in the context Map.
>
> 2. Hans is willing to accept the design, as long as there are no
> undocumented "surprises" where the setting is changed in web.xml files.
> Some web applications that require the setting to be off even when the
> default is on are okay.
>
> 3. I asked Hans for a confirmation that my understanding of his replies
> is correct. He has not replied.
>
> 4. If there are no further objections, then we can proceed with
> implementing the design.
>
> -Adrian
>
>
> On 9/19/2011 10:23 AM, Adrian Crum wrote:
> > Hans,
> >
> > We can document the behavior in the properties file, and we have this
> > discussion on record to describe the behavior and the reason why it
> > was done that way. I believe those things will help avoid confusion in
> > the future.
> >
> > So, can we implement the behavior I described? I believe you already
> > answered this question, but I am asking again just to be sure.
> >
> > -Adrian
> >
> > On 9/19/2011 10:14 AM, Hans Bakker wrote:
> >> If i use the widget comments option i want it to be generally applied
> >> and taken away depending on the properties setting. I do not want to
> >> find out that somewhere it is not following the setting, then have to
> >> dig in the code and find out that is, because somebody put an
> >> undocumented override somewhere by default as happened the first time.
> >> Bird and google checkout is fine.
> >>
> >> I think how it is implemented now is fine. I hope i commented now
> >> enough?
> >>
> >> Regards,
> >> Hans
> >>
> >> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
> >>> Hans,
> >>>
> >>> Jacques gave some examples of where an override is currently used and
> >>> why it is needed. Could you give us another reason besides "i think an
> >>> override is an overkill" - like a reason based on a design issue or a
> >>> real-world problem?
> >>>
> >>> -Adrian
> >>>
> >>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
> >>>> I as sorry i do not see the problem here.....
> >>>>
> >>>> as long as the properties setting in the trunk will show or hide all
> >>>> widget comments (so in the trunk NO override) then it is fine.
> >>>>
> >>>> why? because i think an override is an overkill anyway....
> >>>>
> >>>> Regards,
> >>>> Hans
> >>>>
> >>>>
> >>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
> >>>>> Yes, but I guess we will set widget.verbose in the properties file
> >>>>> to true (as we do for all defaults to be dev friendly). Will that
> >>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
> >>>>> For instance what for Birt by defaut? Why not keeping the example
> >>>>> in example component commented out? Waht for testtools? Not sure
> >>>>> why it's false in googlecheckout but I guess there is a reason..
> >>>>>
> >>>>> In other word I guess Hans expect widget.verbose in the properties
> >>>>> file to be false...
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>> From: "Adrian Crum"<[hidden email]>
> >>>>>> Let's see if we can bring this to a happy ending.
> >>>>>>
> >>>>>> If the widget.verbose setting in the properties file is false,
> >>>>>> then it overrides any other setting and all boundary comments are
> >>>>>> shut off.
> >>>>>>
> >>>>>> If the widget.verbose setting in the properties file is true,
> >>>>>> then it follows the previous pattern, where true is the default, but
> >>>>>> it can be overridden in web.xml and in the context Map.
> >>>>>>
> >>>>>> Will that work for everyone?
> >>>>>>
> >>>>>> -Adrian
> >>>>>>
> >>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
> >>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
> >>>>>>> I agree with Jacques that the formatting of boundary comments
> >>>>>>> should be output specific (i.e no output for CSV etc...) instead of
> >>>>>>> always rendering as html comments.
> >>>>>>> As regards the logic to determine if comments should be enabled
> >>>>>>> or not, I don't have a strong opinion because I have always used
> >>>>>>> this feature in a very rough way (enable all or disable all);
> >>>>>>> however I can understand the we may want to avoid that (when
> >>>>>>> widget.properties.enableBoundaryComments == false) the comments
> >>>>>>> are enabled by passing a URL parameter to the screen.
> >>>>>>>
> >>>>>>> Kind regards,
> >>>>>>>
> >>>>>>> Jacopo
> >>>>>>>
> >>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
> >>>>>>>
> >>>>>>>> Someone I work with suggested:
> >>>>>>>>
> >>>>>>>> I have to point out though that I kind of agree with the way
> >>>>>>>> David put it in that the "false" setting could have a priority,
> >>>>>>>> i.e. it's like in security permissions where "deny" has
> >>>>>>>> precedence over allow, so if you set it in widget.properties to
> >>>>>>>> false
> >>>>>>>> then you're sure comments will never be enabled anywhere...
> >>>>>>>> security-wise it makes sense despite the comment about qc...
> >>>>>>>>
> >>>>>>>> Maybe something like this? (compromise between the two)
> >>>>>>>>
> >>>>>>>> if (widget.properties.enableBoundaryComments == false
> >>>>>>>>          || web.xml.enableBoundaryComments == false
> >>>>>>>>          || context.enableBoundaryComments == false) {
> >>>>>>>>      return false;
> >>>>>>>> } else { // This is the solution Scott wrote, but use
> >>>>>>>> overriding settings only for null and true values
> >>>>>>>>      if (context.enableBoundaryComments != null) return
> >>>>>>>> context.enableBoundaryComments;
> >>>>>>>>      if (web.xml.enableBoundaryComments != null) return
> >>>>>>>> web.xml.enableBoundaryComments;
> >>>>>>>>      if (widget.properties.enableBoundaryComments != null)
> >>>>>>>> return widget.properties.enableBoundaryComments;
> >>>>>>>>      return false;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> Could probably rewrite that to be less redundant but you get
> >>>>>>>> the idea...
> >>>>>>>>
> >>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
> >>>>>>>> idea to me, what do you think?
> >>>>>>>>
> >>>>>>>> Also my colleague also wrote:
> >>>>>>>> Only thing I have to add is that I didn't see anyone address
> >>>>>>>> the issue that HTML comments are outputted for CSV (because
> >>>>>>>> there's
> >>>>>>>> no<csv>    element and you have to use<html>) element. No
> >>>>>>>> matter what widget.verbose is set to, there should never be HTmL
> >>>>>>>> comments outputted for csv. so this only addresses half the
> >>>>>>>> bugs...
> >>>>>>>>
> >>>>>>>> We have no patches so far...
> >>>>>>>>
> >>>>>>>> Jacques
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Dimitri Unruh wrote:
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Dimitri Unruh
> >>>>>>>>> Consultant AEW
> >>>>>>>>> Lynx-Consulting GmbH
> >>>>>>>>> Johanniskirchplatz 6
> >>>>>>>>> 33615 Bielefeld
> >>>>>>>>> Deutschland
> >>>>>>>>> Fon: [phone]
> >>>>>>>>> Fax: [phone]
> >>>>>>>>> Mobil: [phone]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Company and Management Headquarters:
> >>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
> >>>>>>>>> Deutschland
> >>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
> >>>>>>>>>
> >>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
> >>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> http://www.lynx.de/haftungsausschluss
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Wir laden Sie herzlich ein:
> >>>>>>>>> DSAG-Jahreskongress
> >>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
> >>>>>>>>> 2 Stand B01
> >>>>>>>>>
> >>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
> >>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
> >>>>>>>>> das
> >>>>>>>>> Thema Mobility!
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
> >>>>>>>>> Ibryam"<[hidden email]>:
> >>>>>>>>>
> >>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
> >>>>>>>>>> <[hidden email]>    wrote:
> >>>>>>>>>>> Thanks Scott - those are my feelings exactly.
> >>>>>>>>>>>
> >>>>>>>>>>> I like the way the design worked previously, and changing it
> >>>>>>>>>>> because a user
> >>>>>>>>>>> might accidentally leave the comments enabled in production
> >>>>>>>>>>> seems silly.
> >>>>>>>>>>> That is a user's QC problem, not a widget comment design
> >>>>>>>>>>> problem.
> >>>>>>>>>>>
> >>>>>>>>>>> -Adrian
> >>>>>>>>>>>
> >>>>>>>>>> + 1
> >>>>>>>>>>
> >>>>>>>>>> Bilgin

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Alternative ofbiz website: http://www.ofbiz.info
http://www.antwebsystems.com : Quality services for competitive rates.

[Adrian Crum-3]

Thank you Hans, but repeating your confusing replies does not make them
any clearer.

I need a simple yes or no answer: May we implement the design I proposed?

-Adrian

On 9/20/2011 2:17 AM, Hans Bakker wrote:

> Ok Adrian, at least for the third time: (five times in a different
> wording)
>
> what i wrote?
>
>> as long as the properties setting in the trunk will show or hide all
>> widget comments (so in the trunk NO override) then it is fine.
> Regards,
> Hans
>
>
> On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote:
>> Thank you everyone for your patience and comments during this
>> discussion. I believe we are near a resolution.
>>
>>   From my perspective, this is where we stand:
>>
>> 1. I proposed the following design based on David's suggestion:
>>
>> If the widget.verbose setting in the properties file is false, then it
>> overrides any other setting and all boundary comments are
>> shut off.
>>
>> If the widget.verbose setting in the properties file is true, then it
>> follows the previous pattern, where true is the default, but
>> it can be overridden in web.xml and in the context Map.
>>
>> 2. Hans is willing to accept the design, as long as there are no
>> undocumented "surprises" where the setting is changed in web.xml files.
>> Some web applications that require the setting to be off even when the
>> default is on are okay.
>>
>> 3. I asked Hans for a confirmation that my understanding of his replies
>> is correct. He has not replied.
>>
>> 4. If there are no further objections, then we can proceed with
>> implementing the design.
>>
>> -Adrian
>>
>>
>> On 9/19/2011 10:23 AM, Adrian Crum wrote:
>>> Hans,
>>>
>>> We can document the behavior in the properties file, and we have this
>>> discussion on record to describe the behavior and the reason why it
>>> was done that way. I believe those things will help avoid confusion in
>>> the future.
>>>
>>> So, can we implement the behavior I described? I believe you already
>>> answered this question, but I am asking again just to be sure.
>>>
>>> -Adrian
>>>
>>> On 9/19/2011 10:14 AM, Hans Bakker wrote:
>>>> If i use the widget comments option i want it to be generally applied
>>>> and taken away depending on the properties setting. I do not want to
>>>> find out that somewhere it is not following the setting, then have to
>>>> dig in the code and find out that is, because somebody put an
>>>> undocumented override somewhere by default as happened the first time.
>>>> Bird and google checkout is fine.
>>>>
>>>> I think how it is implemented now is fine. I hope i commented now
>>>> enough?
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>>>> Hans,
>>>>>
>>>>> Jacques gave some examples of where an override is currently used and
>>>>> why it is needed. Could you give us another reason besides "i think an
>>>>> override is an overkill" - like a reason based on a design issue or a
>>>>> real-world problem?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>>>> I as sorry i do not see the problem here.....
>>>>>>
>>>>>> as long as the properties setting in the trunk will show or hide all
>>>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>>>
>>>>>> why? because i think an override is an overkill anyway....
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>>>> Yes, but I guess we will set widget.verbose in the properties file
>>>>>>> to true (as we do for all defaults to be dev friendly). Will that
>>>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
>>>>>>> For instance what for Birt by defaut? Why not keeping the example
>>>>>>> in example component commented out? Waht for testtools? Not sure
>>>>>>> why it's false in googlecheckout but I guess there is a reason..
>>>>>>>
>>>>>>> In other word I guess Hans expect widget.verbose in the properties
>>>>>>> file to be false...
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>>>
>>>>>>>> If the widget.verbose setting in the properties file is false,
>>>>>>>> then it overrides any other setting and all boundary comments are
>>>>>>>> shut off.
>>>>>>>>
>>>>>>>> If the widget.verbose setting in the properties file is true,
>>>>>>>> then it follows the previous pattern, where true is the default, but
>>>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>>>
>>>>>>>> Will that work for everyone?
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
>>>>>>>>> I agree with Jacques that the formatting of boundary comments
>>>>>>>>> should be output specific (i.e no output for CSV etc...) instead of
>>>>>>>>> always rendering as html comments.
>>>>>>>>> As regards the logic to determine if comments should be enabled
>>>>>>>>> or not, I don't have a strong opinion because I have always used
>>>>>>>>> this feature in a very rough way (enable all or disable all);
>>>>>>>>> however I can understand the we may want to avoid that (when
>>>>>>>>> widget.properties.enableBoundaryComments == false) the comments
>>>>>>>>> are enabled by passing a URL parameter to the screen.
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>>>
>>>>>>>>>> Someone I work with suggested:
>>>>>>>>>>
>>>>>>>>>> I have to point out though that I kind of agree with the way
>>>>>>>>>> David put it in that the "false" setting could have a priority,
>>>>>>>>>> i.e. it's like in security permissions where "deny" has
>>>>>>>>>> precedence over allow, so if you set it in widget.properties to
>>>>>>>>>> false
>>>>>>>>>> then you're sure comments will never be enabled anywhere...
>>>>>>>>>> security-wise it makes sense despite the comment about qc...
>>>>>>>>>>
>>>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>>>
>>>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>>>           || web.xml.enableBoundaryComments == false
>>>>>>>>>>           || context.enableBoundaryComments == false) {
>>>>>>>>>>       return false;
>>>>>>>>>> } else { // This is the solution Scott wrote, but use
>>>>>>>>>> overriding settings only for null and true values
>>>>>>>>>>       if (context.enableBoundaryComments != null) return
>>>>>>>>>> context.enableBoundaryComments;
>>>>>>>>>>       if (web.xml.enableBoundaryComments != null) return
>>>>>>>>>> web.xml.enableBoundaryComments;
>>>>>>>>>>       if (widget.properties.enableBoundaryComments != null)
>>>>>>>>>> return widget.properties.enableBoundaryComments;
>>>>>>>>>>       return false;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Could probably rewrite that to be less redundant but you get
>>>>>>>>>> the idea...
>>>>>>>>>>
>>>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
>>>>>>>>>> idea to me, what do you think?
>>>>>>>>>>
>>>>>>>>>> Also my colleague also wrote:
>>>>>>>>>> Only thing I have to add is that I didn't see anyone address
>>>>>>>>>> the issue that HTML comments are outputted for CSV (because
>>>>>>>>>> there's
>>>>>>>>>> no<csv>     element and you have to use<html>) element. No
>>>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
>>>>>>>>>> comments outputted for csv. so this only addresses half the
>>>>>>>>>> bugs...
>>>>>>>>>>
>>>>>>>>>> We have no patches so far...
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Dimitri Unruh
>>>>>>>>>>> Consultant AEW
>>>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>>>> 33615 Bielefeld
>>>>>>>>>>> Deutschland
>>>>>>>>>>> Fon: [phone]
>>>>>>>>>>> Fax: [phone]
>>>>>>>>>>> Mobil: [phone]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Company and Management Headquarters:
>>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>>>> Deutschland
>>>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>>>
>>>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
>>>>>>>>>>> 2 Stand B01
>>>>>>>>>>>
>>>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
>>>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
>>>>>>>>>>> das
>>>>>>>>>>> Thema Mobility!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
>>>>>>>>>>> Ibryam"<[hidden email]>:
>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>>>> <[hidden email]>     wrote:
>>>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I like the way the design worked previously, and changing it
>>>>>>>>>>>>> because a user
>>>>>>>>>>>>> might accidentally leave the comments enabled in production
>>>>>>>>>>>>> seems silly.
>>>>>>>>>>>>> That is a user's QC problem, not a widget comment design
>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>
>>>>>>>>>>>> + 1
>>>>>>>>>>>>
>>>>>>>>>>>> Bilgin

[hans_bakker]

Sorry my English Adrian, as usual, every change in the system you make
as difficult as possible, technically you are very good and from that
point of view happy to have you in the community, but communication and
consideration of end users, no one is perfect....so sure (that means
YES) you can go ahead.

Regards
Hans

On Tue, 2011-09-20 at 02:21 +0100, Adrian Crum wrote:

> Thank you Hans, but repeating your confusing replies does not make them
> any clearer.
>
> I need a simple yes or no answer: May we implement the design I proposed?
>
> -Adrian
>
> On 9/20/2011 2:17 AM, Hans Bakker wrote:
> > Ok Adrian, at least for the third time: (five times in a different
> > wording)
> >
> > what i wrote?
> >
> >> as long as the properties setting in the trunk will show or hide all
> >> widget comments (so in the trunk NO override) then it is fine.
> > Regards,
> > Hans
> >
> >
> > On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote:
> >> Thank you everyone for your patience and comments during this
> >> discussion. I believe we are near a resolution.
> >>
> >>   From my perspective, this is where we stand:
> >>
> >> 1. I proposed the following design based on David's suggestion:
> >>
> >> If the widget.verbose setting in the properties file is false, then it
> >> overrides any other setting and all boundary comments are
> >> shut off.
> >>
> >> If the widget.verbose setting in the properties file is true, then it
> >> follows the previous pattern, where true is the default, but
> >> it can be overridden in web.xml and in the context Map.
> >>
> >> 2. Hans is willing to accept the design, as long as there are no
> >> undocumented "surprises" where the setting is changed in web.xml files.
> >> Some web applications that require the setting to be off even when the
> >> default is on are okay.
> >>
> >> 3. I asked Hans for a confirmation that my understanding of his replies
> >> is correct. He has not replied.
> >>
> >> 4. If there are no further objections, then we can proceed with
> >> implementing the design.
> >>
> >> -Adrian
> >>
> >>
> >> On 9/19/2011 10:23 AM, Adrian Crum wrote:
> >>> Hans,
> >>>
> >>> We can document the behavior in the properties file, and we have this
> >>> discussion on record to describe the behavior and the reason why it
> >>> was done that way. I believe those things will help avoid confusion in
> >>> the future.
> >>>
> >>> So, can we implement the behavior I described? I believe you already
> >>> answered this question, but I am asking again just to be sure.
> >>>
> >>> -Adrian
> >>>
> >>> On 9/19/2011 10:14 AM, Hans Bakker wrote:
> >>>> If i use the widget comments option i want it to be generally applied
> >>>> and taken away depending on the properties setting. I do not want to
> >>>> find out that somewhere it is not following the setting, then have to
> >>>> dig in the code and find out that is, because somebody put an
> >>>> undocumented override somewhere by default as happened the first time.
> >>>> Bird and google checkout is fine.
> >>>>
> >>>> I think how it is implemented now is fine. I hope i commented now
> >>>> enough?
> >>>>
> >>>> Regards,
> >>>> Hans
> >>>>
> >>>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
> >>>>> Hans,
> >>>>>
> >>>>> Jacques gave some examples of where an override is currently used and
> >>>>> why it is needed. Could you give us another reason besides "i think an
> >>>>> override is an overkill" - like a reason based on a design issue or a
> >>>>> real-world problem?
> >>>>>
> >>>>> -Adrian
> >>>>>
> >>>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
> >>>>>> I as sorry i do not see the problem here.....
> >>>>>>
> >>>>>> as long as the properties setting in the trunk will show or hide all
> >>>>>> widget comments (so in the trunk NO override) then it is fine.
> >>>>>>
> >>>>>> why? because i think an override is an overkill anyway....
> >>>>>>
> >>>>>> Regards,
> >>>>>> Hans
> >>>>>>
> >>>>>>
> >>>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
> >>>>>>> Yes, but I guess we will set widget.verbose in the properties file
> >>>>>>> to true (as we do for all defaults to be dev friendly). Will that
> >>>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
> >>>>>>> For instance what for Birt by defaut? Why not keeping the example
> >>>>>>> in example component commented out? Waht for testtools? Not sure
> >>>>>>> why it's false in googlecheckout but I guess there is a reason..
> >>>>>>>
> >>>>>>> In other word I guess Hans expect widget.verbose in the properties
> >>>>>>> file to be false...
> >>>>>>>
> >>>>>>> Jacques
> >>>>>>>
> >>>>>>> From: "Adrian Crum"<[hidden email]>
> >>>>>>>> Let's see if we can bring this to a happy ending.
> >>>>>>>>
> >>>>>>>> If the widget.verbose setting in the properties file is false,
> >>>>>>>> then it overrides any other setting and all boundary comments are
> >>>>>>>> shut off.
> >>>>>>>>
> >>>>>>>> If the widget.verbose setting in the properties file is true,
> >>>>>>>> then it follows the previous pattern, where true is the default, but
> >>>>>>>> it can be overridden in web.xml and in the context Map.
> >>>>>>>>
> >>>>>>>> Will that work for everyone?
> >>>>>>>>
> >>>>>>>> -Adrian
> >>>>>>>>
> >>>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
> >>>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
> >>>>>>>>> I agree with Jacques that the formatting of boundary comments
> >>>>>>>>> should be output specific (i.e no output for CSV etc...) instead of
> >>>>>>>>> always rendering as html comments.
> >>>>>>>>> As regards the logic to determine if comments should be enabled
> >>>>>>>>> or not, I don't have a strong opinion because I have always used
> >>>>>>>>> this feature in a very rough way (enable all or disable all);
> >>>>>>>>> however I can understand the we may want to avoid that (when
> >>>>>>>>> widget.properties.enableBoundaryComments == false) the comments
> >>>>>>>>> are enabled by passing a URL parameter to the screen.
> >>>>>>>>>
> >>>>>>>>> Kind regards,
> >>>>>>>>>
> >>>>>>>>> Jacopo
> >>>>>>>>>
> >>>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
> >>>>>>>>>
> >>>>>>>>>> Someone I work with suggested:
> >>>>>>>>>>
> >>>>>>>>>> I have to point out though that I kind of agree with the way
> >>>>>>>>>> David put it in that the "false" setting could have a priority,
> >>>>>>>>>> i.e. it's like in security permissions where "deny" has
> >>>>>>>>>> precedence over allow, so if you set it in widget.properties to
> >>>>>>>>>> false
> >>>>>>>>>> then you're sure comments will never be enabled anywhere...
> >>>>>>>>>> security-wise it makes sense despite the comment about qc...
> >>>>>>>>>>
> >>>>>>>>>> Maybe something like this? (compromise between the two)
> >>>>>>>>>>
> >>>>>>>>>> if (widget.properties.enableBoundaryComments == false
> >>>>>>>>>>           || web.xml.enableBoundaryComments == false
> >>>>>>>>>>           || context.enableBoundaryComments == false) {
> >>>>>>>>>>       return false;
> >>>>>>>>>> } else { // This is the solution Scott wrote, but use
> >>>>>>>>>> overriding settings only for null and true values
> >>>>>>>>>>       if (context.enableBoundaryComments != null) return
> >>>>>>>>>> context.enableBoundaryComments;
> >>>>>>>>>>       if (web.xml.enableBoundaryComments != null) return
> >>>>>>>>>> web.xml.enableBoundaryComments;
> >>>>>>>>>>       if (widget.properties.enableBoundaryComments != null)
> >>>>>>>>>> return widget.properties.enableBoundaryComments;
> >>>>>>>>>>       return false;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> Could probably rewrite that to be less redundant but you get
> >>>>>>>>>> the idea...
> >>>>>>>>>>
> >>>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
> >>>>>>>>>> idea to me, what do you think?
> >>>>>>>>>>
> >>>>>>>>>> Also my colleague also wrote:
> >>>>>>>>>> Only thing I have to add is that I didn't see anyone address
> >>>>>>>>>> the issue that HTML comments are outputted for CSV (because
> >>>>>>>>>> there's
> >>>>>>>>>> no<csv>     element and you have to use<html>) element. No
> >>>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
> >>>>>>>>>> comments outputted for csv. so this only addresses half the
> >>>>>>>>>> bugs...
> >>>>>>>>>>
> >>>>>>>>>> We have no patches so far...
> >>>>>>>>>>
> >>>>>>>>>> Jacques
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Dimitri Unruh wrote:
> >>>>>>>>>>> +1
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Dimitri Unruh
> >>>>>>>>>>> Consultant AEW
> >>>>>>>>>>> Lynx-Consulting GmbH
> >>>>>>>>>>> Johanniskirchplatz 6
> >>>>>>>>>>> 33615 Bielefeld
> >>>>>>>>>>> Deutschland
> >>>>>>>>>>> Fon: [phone]
> >>>>>>>>>>> Fax: [phone]
> >>>>>>>>>>> Mobil: [phone]
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Company and Management Headquarters:
> >>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
> >>>>>>>>>>> Deutschland
> >>>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
> >>>>>>>>>>>
> >>>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
> >>>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> http://www.lynx.de/haftungsausschluss
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Wir laden Sie herzlich ein:
> >>>>>>>>>>> DSAG-Jahreskongress
> >>>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
> >>>>>>>>>>> 2 Stand B01
> >>>>>>>>>>>
> >>>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
> >>>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
> >>>>>>>>>>> das
> >>>>>>>>>>> Thema Mobility!
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
> >>>>>>>>>>> Ibryam"<[hidden email]>:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
> >>>>>>>>>>>> <[hidden email]>     wrote:
> >>>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I like the way the design worked previously, and changing it
> >>>>>>>>>>>>> because a user
> >>>>>>>>>>>>> might accidentally leave the comments enabled in production
> >>>>>>>>>>>>> seems silly.
> >>>>>>>>>>>>> That is a user's QC problem, not a widget comment design
> >>>>>>>>>>>>> problem.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Adrian
> >>>>>>>>>>>>>
> >>>>>>>>>>>> + 1
> >>>>>>>>>>>>
> >>>>>>>>>>>> Bilgin

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Alternative ofbiz website: http://www.ofbiz.info
http://www.antwebsystems.com : Quality services for competitive rates.

[Adrian Crum-3]

Thank you Hans.

I will work on the proposed design and get it committed. If there are
any issues with the commit, I hope we can discuss them here and not
engage in a commit war.

-Adrian


On 9/20/2011 2:31 AM, Hans Bakker wrote:

> Sorry my English Adrian, as usual, every change in the system you make
> as difficult as possible, technically you are very good and from that
> point of view happy to have you in the community, but communication and
> consideration of end users, no one is perfect....so sure (that means
> YES) you can go ahead.
>
> Regards
> Hans
>
> On Tue, 2011-09-20 at 02:21 +0100, Adrian Crum wrote:
>> Thank you Hans, but repeating your confusing replies does not make them
>> any clearer.
>>
>> I need a simple yes or no answer: May we implement the design I proposed?
>>
>> -Adrian
>>
>> On 9/20/2011 2:17 AM, Hans Bakker wrote:
>>> Ok Adrian, at least for the third time: (five times in a different
>>> wording)
>>>
>>> what i wrote?
>>>
>>>> as long as the properties setting in the trunk will show or hide all
>>>> widget comments (so in the trunk NO override) then it is fine.
>>> Regards,
>>> Hans
>>>
>>>
>>> On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote:
>>>> Thank you everyone for your patience and comments during this
>>>> discussion. I believe we are near a resolution.
>>>>
>>>>    From my perspective, this is where we stand:
>>>>
>>>> 1. I proposed the following design based on David's suggestion:
>>>>
>>>> If the widget.verbose setting in the properties file is false, then it
>>>> overrides any other setting and all boundary comments are
>>>> shut off.
>>>>
>>>> If the widget.verbose setting in the properties file is true, then it
>>>> follows the previous pattern, where true is the default, but
>>>> it can be overridden in web.xml and in the context Map.
>>>>
>>>> 2. Hans is willing to accept the design, as long as there are no
>>>> undocumented "surprises" where the setting is changed in web.xml files.
>>>> Some web applications that require the setting to be off even when the
>>>> default is on are okay.
>>>>
>>>> 3. I asked Hans for a confirmation that my understanding of his replies
>>>> is correct. He has not replied.
>>>>
>>>> 4. If there are no further objections, then we can proceed with
>>>> implementing the design.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 9/19/2011 10:23 AM, Adrian Crum wrote:
>>>>> Hans,
>>>>>
>>>>> We can document the behavior in the properties file, and we have this
>>>>> discussion on record to describe the behavior and the reason why it
>>>>> was done that way. I believe those things will help avoid confusion in
>>>>> the future.
>>>>>
>>>>> So, can we implement the behavior I described? I believe you already
>>>>> answered this question, but I am asking again just to be sure.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 9/19/2011 10:14 AM, Hans Bakker wrote:
>>>>>> If i use the widget comments option i want it to be generally applied
>>>>>> and taken away depending on the properties setting. I do not want to
>>>>>> find out that somewhere it is not following the setting, then have to
>>>>>> dig in the code and find out that is, because somebody put an
>>>>>> undocumented override somewhere by default as happened the first time.
>>>>>> Bird and google checkout is fine.
>>>>>>
>>>>>> I think how it is implemented now is fine. I hope i commented now
>>>>>> enough?
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>> On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
>>>>>>> Hans,
>>>>>>>
>>>>>>> Jacques gave some examples of where an override is currently used and
>>>>>>> why it is needed. Could you give us another reason besides "i think an
>>>>>>> override is an overkill" - like a reason based on a design issue or a
>>>>>>> real-world problem?
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 9/19/2011 7:55 AM, Hans Bakker wrote:
>>>>>>>> I as sorry i do not see the problem here.....
>>>>>>>>
>>>>>>>> as long as the properties setting in the trunk will show or hide all
>>>>>>>> widget comments (so in the trunk NO override) then it is fine.
>>>>>>>>
>>>>>>>> why? because i think an override is an overkill anyway....
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hans
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
>>>>>>>>> Yes, but I guess we will set widget.verbose in the properties file
>>>>>>>>> to true (as we do for all defaults to be dev friendly). Will that
>>>>>>>>> suit Hans? Else why do you Hans ask for now overriding in web.xml?
>>>>>>>>> For instance what for Birt by defaut? Why not keeping the example
>>>>>>>>> in example component commented out? Waht for testtools? Not sure
>>>>>>>>> why it's false in googlecheckout but I guess there is a reason..
>>>>>>>>>
>>>>>>>>> In other word I guess Hans expect widget.verbose in the properties
>>>>>>>>> file to be false...
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> From: "Adrian Crum"<[hidden email]>
>>>>>>>>>> Let's see if we can bring this to a happy ending.
>>>>>>>>>>
>>>>>>>>>> If the widget.verbose setting in the properties file is false,
>>>>>>>>>> then it overrides any other setting and all boundary comments are
>>>>>>>>>> shut off.
>>>>>>>>>>
>>>>>>>>>> If the widget.verbose setting in the properties file is true,
>>>>>>>>>> then it follows the previous pattern, where true is the default, but
>>>>>>>>>> it can be overridden in web.xml and in the context Map.
>>>>>>>>>>
>>>>>>>>>> Will that work for everyone?
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
>>>>>>>>>>> I am going to feel bad if I don't add my 2 cents to this thread :-)
>>>>>>>>>>> I agree with Jacques that the formatting of boundary comments
>>>>>>>>>>> should be output specific (i.e no output for CSV etc...) instead of
>>>>>>>>>>> always rendering as html comments.
>>>>>>>>>>> As regards the logic to determine if comments should be enabled
>>>>>>>>>>> or not, I don't have a strong opinion because I have always used
>>>>>>>>>>> this feature in a very rough way (enable all or disable all);
>>>>>>>>>>> however I can understand the we may want to avoid that (when
>>>>>>>>>>> widget.properties.enableBoundaryComments == false) the comments
>>>>>>>>>>> are enabled by passing a URL parameter to the screen.
>>>>>>>>>>>
>>>>>>>>>>> Kind regards,
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>> On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Someone I work with suggested:
>>>>>>>>>>>>
>>>>>>>>>>>> I have to point out though that I kind of agree with the way
>>>>>>>>>>>> David put it in that the "false" setting could have a priority,
>>>>>>>>>>>> i.e. it's like in security permissions where "deny" has
>>>>>>>>>>>> precedence over allow, so if you set it in widget.properties to
>>>>>>>>>>>> false
>>>>>>>>>>>> then you're sure comments will never be enabled anywhere...
>>>>>>>>>>>> security-wise it makes sense despite the comment about qc...
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe something like this? (compromise between the two)
>>>>>>>>>>>>
>>>>>>>>>>>> if (widget.properties.enableBoundaryComments == false
>>>>>>>>>>>>            || web.xml.enableBoundaryComments == false
>>>>>>>>>>>>            || context.enableBoundaryComments == false) {
>>>>>>>>>>>>        return false;
>>>>>>>>>>>> } else { // This is the solution Scott wrote, but use
>>>>>>>>>>>> overriding settings only for null and true values
>>>>>>>>>>>>        if (context.enableBoundaryComments != null) return
>>>>>>>>>>>> context.enableBoundaryComments;
>>>>>>>>>>>>        if (web.xml.enableBoundaryComments != null) return
>>>>>>>>>>>> web.xml.enableBoundaryComments;
>>>>>>>>>>>>        if (widget.properties.enableBoundaryComments != null)
>>>>>>>>>>>> return widget.properties.enableBoundaryComments;
>>>>>>>>>>>>        return false;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Could probably rewrite that to be less redundant but you get
>>>>>>>>>>>> the idea...
>>>>>>>>>>>>
>>>>>>>>>>>> jleroux: I quickly reformated my own way ;o), It seems a good
>>>>>>>>>>>> idea to me, what do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Also my colleague also wrote:
>>>>>>>>>>>> Only thing I have to add is that I didn't see anyone address
>>>>>>>>>>>> the issue that HTML comments are outputted for CSV (because
>>>>>>>>>>>> there's
>>>>>>>>>>>> no<csv>      element and you have to use<html>) element. No
>>>>>>>>>>>> matter what widget.verbose is set to, there should never be HTmL
>>>>>>>>>>>> comments outputted for csv. so this only addresses half the
>>>>>>>>>>>> bugs...
>>>>>>>>>>>>
>>>>>>>>>>>> We have no patches so far...
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Dimitri Unruh wrote:
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dimitri Unruh
>>>>>>>>>>>>> Consultant AEW
>>>>>>>>>>>>> Lynx-Consulting GmbH
>>>>>>>>>>>>> Johanniskirchplatz 6
>>>>>>>>>>>>> 33615 Bielefeld
>>>>>>>>>>>>> Deutschland
>>>>>>>>>>>>> Fon: [phone]
>>>>>>>>>>>>> Fax: [phone]
>>>>>>>>>>>>> Mobil: [phone]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Company and Management Headquarters:
>>>>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>>>>>> Deutschland
>>>>>>>>>>>>> Fon: [phone], Fax: [phone], www.lynx.de
>>>>>>>>>>>>>
>>>>>>>>>>>>> Court Registration: Amtsgericht Bielefeld HRB 35946
>>>>>>>>>>>>> Chief Executive Officers: Karsten Noss, Dirk Osterkamp
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://www.lynx.de/haftungsausschluss
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wir laden Sie herzlich ein:
>>>>>>>>>>>>> DSAG-Jahreskongress
>>>>>>>>>>>>> Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle
>>>>>>>>>>>>> 2 Stand B01
>>>>>>>>>>>>>
>>>>>>>>>>>>> Besuchen Sie uns an unserem Stand und freuen Sie sich auf
>>>>>>>>>>>>> einen intensiven Informations- und Erfahrungsaustausch rund um
>>>>>>>>>>>>> das
>>>>>>>>>>>>> Thema Mobility!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Am 13.09.2011 um 14:35 schrieb "Bilgin
>>>>>>>>>>>>> Ibryam"<[hidden email]>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>>>>>> <[hidden email]>      wrote:
>>>>>>>>>>>>>>> Thanks Scott - those are my feelings exactly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I like the way the design worked previously, and changing it
>>>>>>>>>>>>>>> because a user
>>>>>>>>>>>>>>> might accidentally leave the comments enabled in production
>>>>>>>>>>>>>>> seems silly.
>>>>>>>>>>>>>>> That is a user's QC problem, not a widget comment design
>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> + 1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bilgin