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"<adrian.c...@sandglass-software.com>
>>>>>>>>> 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: +49 521 5247-0
>>>>>>>>>>>> Fax: +49 521 5247-250
>>>>>>>>>>>> Mobil: +49 160 90 57 55 13
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Company and Management Headquarters:
>>>>>>>>>>>> Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
>>>>>>>>>>>> Deutschland
>>>>>>>>>>>> Fon: +49 521 5247-0, Fax: +49 521 5247-250, 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"<bibr...@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
>>>>>>>>>>>>> <adrian.c...@sandglass-software.com> 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
>
