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
>
