Fw: widgetVerbose

[Adrian Crum-3]

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


On 9/13/2011 8:55 AM, Scott Gray wrote:

> Sorry I'm a bit lost, is the latest proposal something like this:
>
> if (widget.properties.enableBoundaryComments == null) {
>
>      // widget.properties not set, only show where specified as true
>      if (context.enableBoundaryComments != null) return context.enableBoundaryComments;
>      return false;
>
> } else if (widget.properties.enableBoundaryComments) {
>
>      // widget.properties set to true, show everywhere unless specified as false
>      if (context.enableBoundaryComments != null) return context.enableBoundaryComments;
>      return true;
>
> } else {
>
>      // widget.properties set to false, show nowhere
>      return false;
>
> }
>
> As opposed to what was originally implemented:
>
> 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;
>
> I still prefer the original solution, in my experience the 99% use case for this setting is:
> - widget.properties.enableBoundaryComments=Y for development (ideally comes this way OOTB)
> - developer uses web.xml or context to set to N for apps/screens where they NEVER want the comments to show up (maybe some CSV screen or something)
> - widget.properties.enableBoundaryComments=N for production
>
> I just can't imagine a reason why widget.properties would be set to N and a developer would decide to turn it on via the web.xml or context and subsequently cause it to be shown in production (i.e. the reverse of the use case I've described above).  It seems like we're complicating an issue that is very unlikely to arise and only did arise because the example app's web.xml was set to Y when it shouldn't have been (which confused Hans and caused him to make sweeping changes instead of just commenting out the web.xml setting).
>
> I really don't think there is a perfect solution but I'd rather advocate a simple one that can easily be remembered.
>
> Regards
> Scott
>
> On 13/09/2011, at 6:41 PM, David E Jones wrote:
>
>> Yes, there is some value in being able to have boundary comments always on… so Adrian are you coming around to agree with the approach Hans introduced?
>>
>> Why don't we use the widget.properties setting if there is one, otherwise look at the parameters Map (i.e. request parameters and web.xml context params). By default, i.e. in SVN, the value will NOT be set.
>>
>> -David
>>
>>
>> On Sep 12, 2011, at 6:45 PM, Adrian Crum wrote:
>>
>>> So we would do away with the ability to specify that boundary comments are always on?
>>>
>>> Having them on by default during development is very helpful - I use them all the time. I can view the page source of any screen to see where the widget XML file is located that generated the screen. It seems to me with the method you proposed, I will not be able to do that - because comments will be off. I would have to hack the URL and add a parameter to see them, or I would have to modify the application's web.xml file and restart the server.
>>>
>>> -Adrian
>>>
>>> On 9/13/2011 2:22 AM, David E Jones wrote:
>>>> Based on this I'm actually reconsidering my position, however the current implementation is still not adequate.
>>>>
>>>> It sounds like the goal for the widget.properties is to make it easy to go into production and make sure that no boundary comments/etc are added anywhere in the system. To do that effectively you need a single setting for the whole system, and that setting should override everything else (i.e. not even allow for a parameter to be manually added which may expose implementation details that you want to keep hidden).
>>>>
>>>> For that purpose a property would make sense, but the logic has to be carefully done (not the shallow logic that has been discussed so far). It would need to be something like: if (widgetVerbose property == false) then don't show else if (widgetVerbose parameter (using default OFBiz parameters Map, takes into account both URL parameters and web.xml context parameters) == true) then show else don't show.
>>>>
>>>> In other words, if the widget.properties setting is false, then never show boundary comments. Otherwise, ignore it and use the parameters value if true, and overall default to false.
>>>>
>>>> Wow, is this really that hard?
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>> On Sep 12, 2011, at 5:03 PM, Hans Bakker wrote:
>>>>
>>>>> As i wrote before i am fine with this if in the trunk the setting of
>>>>> widget.properties is not overridden by default in web.xml for some
>>>>> component what was the case originally.
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>> On Mon, 2011-09-12 at 20:02 +0100, Adrian Crum wrote:
>>>>>> David,
>>>>>>
>>>>>> Keep in mind that the original design is one that you participated in.
>>>>>> The agreement on the setting precedence in the original Jira issue was this:
>>>>>>
>>>>>> widget.properties ->   web.xml ->   URL parameters
>>>>>>
>>>>>> where widget.properties is the global default, which can be overridden
>>>>>> by a setting in web.xml, which can be overridden by screen widgets or
>>>>>> scripts or whatever (via the current context Map).
>>>>>>
>>>>>> The design worked great. Then Hans changed it due to a misunderstanding
>>>>>> of how the design works. Despite repeated explanations of how the design
>>>>>> works, and requests from three PMC members to revert his change, he
>>>>>> refused to change it and threatened the community with a commit war.
>>>>>> Since then we have had a number of issues reported on the mailing list
>>>>>> describing how his change makes the setting unusable.
>>>>>>
>>>>>> It amazes me that a single -1 vote vetoes a change in the Apache
>>>>>> community, but three -1 votes from PMC members can't revert this obvious
>>>>>> break in software design.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 9/12/2011 7:24 PM, Adrian Crum wrote:
>>>>>>> No. The approach suggested by (and committed by) Hans is that the
>>>>>>> setting in the widget.properties file overrides any other setting.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 9/12/2011 6:19 PM, David E Jones wrote:
>>>>>>>> No one agrees with which approach? The approach that if you pass a
>>>>>>>> widgetVerbose=true HTTP parameter that it should override the
>>>>>>>> widget.properties setting? I agree with that approach…
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sep 12, 2011, at 6:59 AM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> That's the problem - no one agrees with that approach.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> On 9/12/2011 1:53 PM, Jacques Le Roux wrote:
>>>>>>>>>> I think I forgot to forward Hans's answer
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>> Hans Bakker wrote:
>>>>>>>>>>> On Wed, 2011-08-31 at 05:15 +0200, Jacques Le Roux wrote:
>>>>>>>>>>>> widget.properties's widget.verbose setting has precedence over
>>>>>>>>>>>> web.xml's widgetVerbose setting. So you can't use
>>>>>>>>>>>> parameters.widgetVerbose to override widget.verbose to false. Is
>>>>>>>>>>>> ModelWidget.widgetBoundaryCommentsEnabled() written this way for
>>>>>>>>>>>> some reasons?
>>>>>>>>>>> there was a lengthly discussion of this. As long as by default the
>>>>>>>>>>> properties file is not overridden in web.xml is fine either way.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Another issue is that these HTML boundary comments get outputted
>>>>>>>>>>>> even though the view handler is set to "screencsv". In the
>>>>>>>>>>>> widget-screen.xsd, the only way to invoke a template to produce
>>>>>>>>>>>> CSV is using<html><html-template />, but this always adds HTML
>>>>>>>>>>>> comments even if the output is CSV (see HtmlWidget class). Maybe
>>>>>>>>>>>> we could introduce a<csv>    element or something like that?
>>>>>>>>>>>>
>>>>>>>>>>>> Anyway, both of those problems combined mean that there are no
>>>>>>>>>>>> apparent clean ways to remove the HTML "template begin/end"
>>>>>>>>>>>> boundary comments from the CSV output if you try to draw it with
>>>>>>>>>>>> an *.ftl template. A workaround  kludge for now is to invoke
>>>>>>>>>>>> the FTL manually through a Groovy script.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>> --
>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>> Alternative ofbiz website: http://www.ofbiz.info
>>>>> http://www.antwebsystems.com : Quality services for competitive rates.
>>>>>

[Jacques Le Roux]

+1

Jacques

From: "Adrian Crum" <[hidden email]>

> 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
>
>
> On 9/13/2011 8:55 AM, Scott Gray wrote:
>> Sorry I'm a bit lost, is the latest proposal something like this:
>>
>> if (widget.properties.enableBoundaryComments == null) {
>>
>>      // widget.properties not set, only show where specified as true
>>      if (context.enableBoundaryComments != null) return context.enableBoundaryComments;
>>      return false;
>>
>> } else if (widget.properties.enableBoundaryComments) {
>>
>>      // widget.properties set to true, show everywhere unless specified as false
>>      if (context.enableBoundaryComments != null) return context.enableBoundaryComments;
>>      return true;
>>
>> } else {
>>
>>      // widget.properties set to false, show nowhere
>>      return false;
>>
>> }
>>
>> As opposed to what was originally implemented:
>>
>> 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;
>>
>> I still prefer the original solution, in my experience the 99% use case for this setting is:
>> - widget.properties.enableBoundaryComments=Y for development (ideally comes this way OOTB)
>> - developer uses web.xml or context to set to N for apps/screens where they NEVER want the comments to show up (maybe some CSV
>> screen or something)
>> - widget.properties.enableBoundaryComments=N for production
>>
>> I just can't imagine a reason why widget.properties would be set to N and a developer would decide to turn it on via the web.xml
>> or context and subsequently cause it to be shown in production (i.e. the reverse of the use case I've described above).  It seems
>> like we're complicating an issue that is very unlikely to arise and only did arise because the example app's web.xml was set to Y
>> when it shouldn't have been (which confused Hans and caused him to make sweeping changes instead of just commenting out the
>> web.xml setting).
>>
>> I really don't think there is a perfect solution but I'd rather advocate a simple one that can easily be remembered.
>>
>> Regards
>> Scott
>>
>> On 13/09/2011, at 6:41 PM, David E Jones wrote:
>>
>>> Yes, there is some value in being able to have boundary comments always on… so Adrian are you coming around to agree with the
>>> approach Hans introduced?
>>>
>>> Why don't we use the widget.properties setting if there is one, otherwise look at the parameters Map (i.e. request parameters
>>> and web.xml context params). By default, i.e. in SVN, the value will NOT be set.
>>>
>>> -David
>>>
>>>
>>> On Sep 12, 2011, at 6:45 PM, Adrian Crum wrote:
>>>
>>>> So we would do away with the ability to specify that boundary comments are always on?
>>>>
>>>> Having them on by default during development is very helpful - I use them all the time. I can view the page source of any
>>>> screen to see where the widget XML file is located that generated the screen. It seems to me with the method you proposed, I
>>>> will not be able to do that - because comments will be off. I would have to hack the URL and add a parameter to see them, or I
>>>> would have to modify the application's web.xml file and restart the server.
>>>>
>>>> -Adrian
>>>>
>>>> On 9/13/2011 2:22 AM, David E Jones wrote:
>>>>> Based on this I'm actually reconsidering my position, however the current implementation is still not adequate.
>>>>>
>>>>> It sounds like the goal for the widget.properties is to make it easy to go into production and make sure that no boundary
>>>>> comments/etc are added anywhere in the system. To do that effectively you need a single setting for the whole system, and that
>>>>> setting should override everything else (i.e. not even allow for a parameter to be manually added which may expose
>>>>> implementation details that you want to keep hidden).
>>>>>
>>>>> For that purpose a property would make sense, but the logic has to be carefully done (not the shallow logic that has been
>>>>> discussed so far). It would need to be something like: if (widgetVerbose property == false) then don't show else if
>>>>> (widgetVerbose parameter (using default OFBiz parameters Map, takes into account both URL parameters and web.xml context
>>>>> parameters) == true) then show else don't show.
>>>>>
>>>>> In other words, if the widget.properties setting is false, then never show boundary comments. Otherwise, ignore it and use the
>>>>> parameters value if true, and overall default to false.
>>>>>
>>>>> Wow, is this really that hard?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>> On Sep 12, 2011, at 5:03 PM, Hans Bakker wrote:
>>>>>
>>>>>> As i wrote before i am fine with this if in the trunk the setting of
>>>>>> widget.properties is not overridden by default in web.xml for some
>>>>>> component what was the case originally.
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>> On Mon, 2011-09-12 at 20:02 +0100, Adrian Crum wrote:
>>>>>>> David,
>>>>>>>
>>>>>>> Keep in mind that the original design is one that you participated in.
>>>>>>> The agreement on the setting precedence in the original Jira issue was this:
>>>>>>>
>>>>>>> widget.properties ->   web.xml ->   URL parameters
>>>>>>>
>>>>>>> where widget.properties is the global default, which can be overridden
>>>>>>> by a setting in web.xml, which can be overridden by screen widgets or
>>>>>>> scripts or whatever (via the current context Map).
>>>>>>>
>>>>>>> The design worked great. Then Hans changed it due to a misunderstanding
>>>>>>> of how the design works. Despite repeated explanations of how the design
>>>>>>> works, and requests from three PMC members to revert his change, he
>>>>>>> refused to change it and threatened the community with a commit war.
>>>>>>> Since then we have had a number of issues reported on the mailing list
>>>>>>> describing how his change makes the setting unusable.
>>>>>>>
>>>>>>> It amazes me that a single -1 vote vetoes a change in the Apache
>>>>>>> community, but three -1 votes from PMC members can't revert this obvious
>>>>>>> break in software design.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 9/12/2011 7:24 PM, Adrian Crum wrote:
>>>>>>>> No. The approach suggested by (and committed by) Hans is that the
>>>>>>>> setting in the widget.properties file overrides any other setting.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 9/12/2011 6:19 PM, David E Jones wrote:
>>>>>>>>> No one agrees with which approach? The approach that if you pass a
>>>>>>>>> widgetVerbose=true HTTP parameter that it should override the
>>>>>>>>> widget.properties setting? I agree with that approach…
>>>>>>>>>
>>>>>>>>> -David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sep 12, 2011, at 6:59 AM, Adrian Crum wrote:
>>>>>>>>>
>>>>>>>>>> That's the problem - no one agrees with that approach.
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> On 9/12/2011 1:53 PM, Jacques Le Roux wrote:
>>>>>>>>>>> I think I forgot to forward Hans's answer
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>> Hans Bakker wrote:
>>>>>>>>>>>> On Wed, 2011-08-31 at 05:15 +0200, Jacques Le Roux wrote:
>>>>>>>>>>>>> widget.properties's widget.verbose setting has precedence over
>>>>>>>>>>>>> web.xml's widgetVerbose setting. So you can't use
>>>>>>>>>>>>> parameters.widgetVerbose to override widget.verbose to false. Is
>>>>>>>>>>>>> ModelWidget.widgetBoundaryCommentsEnabled() written this way for
>>>>>>>>>>>>> some reasons?
>>>>>>>>>>>> there was a lengthly discussion of this. As long as by default the
>>>>>>>>>>>> properties file is not overridden in web.xml is fine either way.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Another issue is that these HTML boundary comments get outputted
>>>>>>>>>>>>> even though the view handler is set to "screencsv". In the
>>>>>>>>>>>>> widget-screen.xsd, the only way to invoke a template to produce
>>>>>>>>>>>>> CSV is using<html><html-template />, but this always adds HTML
>>>>>>>>>>>>> comments even if the output is CSV (see HtmlWidget class). Maybe
>>>>>>>>>>>>> we could introduce a<csv>    element or something like that?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyway, both of those problems combined mean that there are no
>>>>>>>>>>>>> apparent clean ways to remove the HTML "template begin/end"
>>>>>>>>>>>>> boundary comments from the CSV output if you try to draw it with
>>>>>>>>>>>>> an *.ftl template. A workaround  kludge for now is to invoke
>>>>>>>>>>>>> the FTL manually through a Groovy script.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>> --
>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>> Alternative ofbiz website: http://www.ofbiz.info
>>>>>> http://www.antwebsystems.com : Quality services for competitive rates.
>>>>>>

[Bilgin Ibryam-2]

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

[Dimitri Unruh-2]

+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

[Jacques Le Roux]

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

[Jacopo Cappellato-4]

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]

Some time ago there was a discussion about coding pattern if not true it
is false.
it was WidgetVerbose which says it had to be true to be verbose.
I don't see changing widget.properties. to enableBoundaryComments
it means those that have production have to become familiar with new.
this goes along it if ain't broke don't fix it.
As far as flow the property ==true should override all other setting
since it is a design function.
The default Should be not true. This means is can be blank or false.
Then all other setting would be in effect.

Jacques Le Roux sent the following on 9/15/2011 7:18 AM:

> 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]

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]

That is fine with me as long as by default there is no active override
in any web.xml

Regards,
Hans

On Mon, 2011-09-19 at 01:52 +0100, Adrian Crum wrote:

> 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]

I still don't know what that means. Could you be more specific please?

-Adrian

On 9/19/2011 1:59 AM, Hans Bakker wrote:

> That is fine with me as long as by default there is no active override
> in any web.xml
>
> Regards,
> Hans
>
> On Mon, 2011-09-19 at 01:52 +0100, Adrian Crum wrote:
>> 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]

that in the trunk there is no override of widget.verbose in any web.xml.

Hans

On Mon, 2011-09-19 at 02:01 +0100, Adrian Crum wrote:

> I still don't know what that means. Could you be more specific please?
>
> -Adrian
>
> On 9/19/2011 1:59 AM, Hans Bakker wrote:
> > That is fine with me as long as by default there is no active override
> > in any web.xml
> >
> > Regards,
> > Hans
> >
> > On Mon, 2011-09-19 at 01:52 +0100, Adrian Crum wrote:
> >> 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]

Why? As far as I know, that is not a problem - but I don't understand
why it should be prohibited.

-Adrian

On 9/19/2011 2:14 AM, Hans Bakker wrote:

> that in the trunk there is no override of widget.verbose in any web.xml.
>
> Hans
>
> On Mon, 2011-09-19 at 02:01 +0100, Adrian Crum wrote:
>> I still don't know what that means. Could you be more specific please?
>>
>> -Adrian
>>
>> On 9/19/2011 1:59 AM, Hans Bakker wrote:
>>> That is fine with me as long as by default there is no active override
>>> in any web.xml
>>>
>>> Regards,
>>> Hans
>>>
>>> On Mon, 2011-09-19 at 01:52 +0100, Adrian Crum wrote:
>>>> 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

[Scott Gray-2]

Because if a web.xml turns off widgetVerbose OOTB, history shows that it will confuse a committer, trigger a rewrite of the entire implementation and the sending of at least 100 messages to the dev list.

Regards
Scott

On 19/09/2011, at 1:16 PM, Adrian Crum wrote:

> Why? As far as I know, that is not a problem - but I don't understand why it should be prohibited.
>
> -Adrian
>
> On 9/19/2011 2:14 AM, Hans Bakker wrote:
>> that in the trunk there is no override of widget.verbose in any web.xml.
>>
>> Hans
>>
>> On Mon, 2011-09-19 at 02:01 +0100, Adrian Crum wrote:
>>> I still don't know what that means. Could you be more specific please?
>>>
>>> -Adrian
>>>
>>> On 9/19/2011 1:59 AM, Hans Bakker wrote:
>>>> That is fine with me as long as by default there is no active override
>>>> in any web.xml
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>> On Mon, 2011-09-19 at 01:52 +0100, Adrian Crum wrote:
>>>>> 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

[Jacques Le Roux]

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]

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]

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]

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]

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

[Jacques Le Roux]

Unfortunately, I believe Hans's answer was

> I think how it is implemented now is fine. I hope i commented now
> enough?

In other words, he does not want to change the way it's done at the moment. Did yoy consider "my proposition" (based on Scott's)
Adrian, Hans? I think it's a good compromise...

Jacques

From: "Adrian Crum" <[hidden email]>

> 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]

Jacques:

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 Mon, 2011-09-19 at 15:24 +0200, Jacques Le Roux wrote:

> Unfortunately, I believe Hans's answer was
>
> > I think how it is implemented now is fine. I hope i commented now
> > enough?
>
> In other words, he does not want to change the way it's done at the moment. Did yoy consider "my proposition" (based on Scott's)
> Adrian, Hans? I think it's a good compromise...
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
> > 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.