Re: widgetVerbose
Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason..
In other word I guess Hans expect widget.verbose in the properties file to be
false...
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all); however I can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put it in that the false setting could have a priority,
i.e. it's like in security permissions where deny has precedence over allow, so if you set it in widget.properties to false
then you're sure comments will never be enabled anywhere... security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding settings only
for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what
do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that HTML comments are outputted for CSV (because there's
nocsv element and you have to usehtml) element. No matter what widget.verbose is set to, there should never be HTmL
comments outputted for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because a user
might accidentally leave the comments enabled in production seems silly.
That is a user's QC problem, not a widget comment design problem.
-Adrian
+ 1
Bilgin
Re: widgetVerbose
I as sorry i do not see the problem here.
as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.
why? because i think an override is an overkill anyway
Regards,
Hans
On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
Yes, but I guess we will set widget.verbose in the properties file to true
(as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml? For
instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure why it's
false in googlecheckout but I guess there is a reason..
In other word I guess Hans expect widget.verbose in the properties file to be
false...
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true, then it
follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be
output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled or not, I
don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all); however I
can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are
enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put it
in that the false setting could have a priority,
i.e. it's like in security permissions where deny has precedence over
allow, so if you set it in widget.properties to false
then you're sure comments will never be enabled anywhere... security-wise
it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding settings
only for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to me,
what do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue
that HTML comments are outputted for CSV (because there's
nocsv element and you have to usehtml) element. No matter what
widget.verbose is set to, there should never be HTmL
comments outputted for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen
intensiven Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because a
user
might accidentally leave the comments enabled in production seems
silly.
That is a user's QC
Re: widgetVerbose
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 Crumadrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true, then it follows
the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output
specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled or not, I don't
have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all); however I can
understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are enabled by
passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put it in that the
false setting could have a priority,
i.e. it's like in security permissions where deny has precedence over allow,
so if you set it in widget.properties to false
then you're sure comments will never be enabled anywhere... security-wise it
makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding settings only
for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what
do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that
HTML comments are outputted for CSV (because there's
nocsv element and you have to usehtml) element. No matter what
widget.verbose is set to, there should never be HTmL
comments outputted for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because a user
might accidentally
Re: widgetVerbose
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 Crumadrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true, then it
follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be
output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled or not,
I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all); however I
can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are
enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put
it in that the false setting could have a priority,
i.e. it's like in security permissions where deny has precedence over
allow, so if you set it in widget.properties to false
then you're sure comments will never be enabled anywhere...
security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding
settings only for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to
me, what do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue
that HTML comments are outputted for CSV (because there's
nocsv element and you have to usehtml) element. No matter what
widget.verbose is set to, there should never be HTmL
comments outputted for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
Deutschland
Fon: +49 521 5247-0, Fax: +49 521
Re: widgetVerbose
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 adrian.c...@sandglass-software.com
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 Crumadrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments
are
shut off.
If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the
default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...)
instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always
used
this feature in a very rough way (enable all or disable all); however I can
understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are enabled by
passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put it in that the false setting could have a
priority,
i.e. it's like in security permissions where deny has precedence over allow, so if you set it in widget.properties to
false
then you're sure comments will never be enabled anywhere... security-wise it
makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding settings only
for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what
do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that HTML comments are outputted for CSV (because
there's
Re: widgetVerbose
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 adrian.c...@sandglass-software.com
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 Crumadrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments
are
shut off.
If the widget.verbose setting in the properties file is true, then it
follows the previous pattern, where true is the
default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should
be output specific (i.e no output for CSV etc...)
instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled or
not, I don't have a strong opinion because I have always
used
this feature in a very rough way (enable all or disable all); however
I can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are
enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David
put it in that the false setting could have a
priority,
i.e. it's like in security permissions where deny has precedence
over allow, so if you set it in widget.properties to
false
then you're sure comments will never be enabled anywhere...
security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding
settings only for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
Re: widgetVerbose
+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component level.
Hans Bakker sent the following on 9/19/2011 2:14 AM:
If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.
I think how it is implemented now is fine. I hope i commented now
enough?
Regards,
Hans
On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
Hans,
Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?
-Adrian
On 9/19/2011 7:55 AM, Hans Bakker wrote:
I as sorry i do not see the problem here.
as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.
why? because i think an override is an overkill anyway
Regards,
Hans
On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
Yes, but I guess we will set widget.verbose in the properties file to true
(as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml? For
instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure why it's
false in googlecheckout but I guess there is a reason..
In other word I guess Hans expect widget.verbose in the properties file to
be false...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true, then it
follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be
output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled or not,
I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all); however I
can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are
enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put
it in that the false setting could have a priority,
i.e. it's like in security permissions where deny has precedence over
allow, so if you set it in widget.properties to false
then you're sure comments will never be enabled anywhere...
security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding
settings only for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to
me, what do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue
that HTML comments are outputted for CSV (because there's
nocsv element and you have to usehtml) element. No matter what
widget.verbose is set to, there should never be HTmL
comments outputted for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Re: widgetVerbose
BJ,
The original message of this thread points out why that approach does
not work. If comments are defaulted to on, then there MUST be a way to
turn them off for things like CSV output.
-Adrian
On 9/19/2011 4:39 PM, BJ Freeman wrote:
+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component level.
Hans Bakker sent the following on 9/19/2011 2:14 AM:
If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.
I think how it is implemented now is fine. I hope i commented now
enough?
Regards,
Hans
On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
Hans,
Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?
-Adrian
On 9/19/2011 7:55 AM, Hans Bakker wrote:
I as sorry i do not see the problem here.
as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.
why? because i think an override is an overkill anyway
Regards,
Hans
On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
Yes, but I guess we will set widget.verbose in the properties file to true (as
we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance
what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure why it's false
in googlecheckout but I guess there is a reason..
In other word I guess Hans expect widget.verbose in the properties file to be
false...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true, then it follows
the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output
specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled or not, I don't
have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all); however I can
understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments are enabled by
passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put it in that the
false setting could have a priority,
i.e. it's like in security permissions where deny has precedence over allow,
so if you set it in widget.properties to false
then you're sure comments will never be enabled anywhere... security-wise it
makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding settings only
for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what
do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that
HTML comments are outputted for CSV (because there's
nocsvelement and you have to usehtml) 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
Re: widgetVerbose
yes I understand. but a simple turn off all comments lets you work with
that. but if you want to see what is generating that, then turn them all on.
Like Hans said, I really don't want to have to go through code to find
where it is turned off or on.
Adrian Crum sent the following on 9/19/2011 8:56 AM:
BJ,
The original message of this thread points out why that approach does
not work. If comments are defaulted to on, then there MUST be a way to
turn them off for things like CSV output.
-Adrian
On 9/19/2011 4:39 PM, BJ Freeman wrote:
+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component level.
Hans Bakker sent the following on 9/19/2011 2:14 AM:
If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.
I think how it is implemented now is fine. I hope i commented now
enough?
Regards,
Hans
On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
Hans,
Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?
-Adrian
On 9/19/2011 7:55 AM, Hans Bakker wrote:
I as sorry i do not see the problem here.
as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.
why? because i think an override is an overkill anyway
Regards,
Hans
On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
Yes, but I guess we will set widget.verbose in the properties file
to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml?
For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure
why it's false in googlecheckout but I guess there is a reason..
In other word I guess Hans expect widget.verbose in the properties
file to be false...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false,
then it overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true,
then it follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments
should be output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled
or not, I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all);
however I can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments
are enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way
David put it in that the false setting could have a priority,
i.e. it's like in security permissions where deny has
precedence over allow, so if you set it in widget.properties to
false
then you're sure comments will never be enabled anywhere...
security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use
overriding settings only for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null)
return widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get
the idea...
jleroux: I quickly reformated my own way ;o), It seems a good
idea to me, what do you think?
Also my colleague also wrote:
Only thing I have to add is
Re: widgetVerbose
And there are others who don't like the all-or-nothing approach. Please,
unless you have something new to add, can we stop talking in circles?
-Adrian
On 9/19/2011 5:02 PM, BJ Freeman wrote:
yes I understand. but a simple turn off all comments lets you work with
that. but if you want to see what is generating that, then turn them all on.
Like Hans said, I really don't want to have to go through code to find
where it is turned off or on.
Adrian Crum sent the following on 9/19/2011 8:56 AM:
BJ,
The original message of this thread points out why that approach does
not work. If comments are defaulted to on, then there MUST be a way to
turn them off for things like CSV output.
-Adrian
On 9/19/2011 4:39 PM, BJ Freeman wrote:
+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component level.
Hans Bakker sent the following on 9/19/2011 2:14 AM:
If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.
I think how it is implemented now is fine. I hope i commented now
enough?
Regards,
Hans
On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
Hans,
Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?
-Adrian
On 9/19/2011 7:55 AM, Hans Bakker wrote:
I as sorry i do not see the problem here.
as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.
why? because i think an override is an overkill anyway
Regards,
Hans
On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
Yes, but I guess we will set widget.verbose in the properties file
to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml?
For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure
why it's false in googlecheckout but I guess there is a reason..
In other word I guess Hans expect widget.verbose in the properties
file to be false...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false,
then it overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true,
then it follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments
should be output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled
or not, I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all);
however I can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments
are enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way
David put it in that the false setting could have a priority,
i.e. it's like in security permissions where deny has
precedence over allow, so if you set it in widget.properties to
false
then you're sure comments will never be enabled anywhere...
security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use
overriding settings only for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null)
return widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get
the idea...
jleroux: I quickly reformated my own way
Re: widgetVerbose
Then I suggest a vote, though mine is none binding.
Adrian Crum sent the following on 9/19/2011 9:06 AM:
And there are others who don't like the all-or-nothing approach. Please,
unless you have something new to add, can we stop talking in circles?
-Adrian
On 9/19/2011 5:02 PM, BJ Freeman wrote:
yes I understand. but a simple turn off all comments lets you work with
that. but if you want to see what is generating that, then turn them
all on.
Like Hans said, I really don't want to have to go through code to find
where it is turned off or on.
Adrian Crum sent the following on 9/19/2011 8:56 AM:
BJ,
The original message of this thread points out why that approach does
not work. If comments are defaulted to on, then there MUST be a way to
turn them off for things like CSV output.
-Adrian
On 9/19/2011 4:39 PM, BJ Freeman wrote:
+1
KISS
one place to turn off and on. common sense says you use for development
then you turn it off so there are no comments in the ouput.
So there is not need to have the comments turned off at component
level.
Hans Bakker sent the following on 9/19/2011 2:14 AM:
If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.
I think how it is implemented now is fine. I hope i commented now
enough?
Regards,
Hans
On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
Hans,
Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i
think an
override is an overkill - like a reason based on a design issue or a
real-world problem?
-Adrian
On 9/19/2011 7:55 AM, Hans Bakker wrote:
I as sorry i do not see the problem here.
as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.
why? because i think an override is an overkill anyway
Regards,
Hans
On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
Yes, but I guess we will set widget.verbose in the properties file
to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml?
For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure
why it's false in googlecheckout but I guess there is a reason..
In other word I guess Hans expect widget.verbose in the properties
file to be false...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false,
then it overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true,
then it follows the previous pattern, where true is the
default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this
thread :-)
I agree with Jacques that the formatting of boundary comments
should be output specific (i.e no output for CSV etc...)
instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled
or not, I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all);
however I can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments
are enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way
David put it in that the false setting could have a priority,
i.e. it's like in security permissions where deny has
precedence over allow, so if you set it in widget.properties to
false
then you're sure comments will never be enabled anywhere...
security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use
overriding settings only for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if
Re: widgetVerbose
If the main problem is not wanting to go through all the code to find where the comments are on/off, perhaps a solution would be log messages at startup saying which comments are turned on where? Then when anyone sees/doesn't see comments they do/don't want, they can look at the startup logs to see exactly what is on and off. And then no one will care as strongly about the details. I'm not familiar with this code, but I'd guess adding a logging statement where each relevant property is loaded wouldn't be difficult? Of course, if they are loaded lots of times all over the place, then it isn't that simple. In which case maybe something in webtools that reports what is on and off and where? Cheers, Anne. On 20 September 2011 02:02, BJ Freeman bjf...@free-man.net wrote: yes I understand. but a simple turn off all comments lets you work with that. but if you want to see what is generating that, then turn them all on. Like Hans said, I really don't want to have to go through code to find where it is turned off or on. Adrian Crum sent the following on 9/19/2011 8:56 AM: BJ, The original message of this thread points out why that approach does not work. If comments are defaulted to on, then there MUST be a way to turn them off for things like CSV output. -Adrian On 9/19/2011 4:39 PM, BJ Freeman wrote: +1 KISS one place to turn off and on. common sense says you use for development then you turn it off so there are no comments in the ouput. So there is not need to have the comments turned off at component level. Hans Bakker sent the following on 9/19/2011 2:14 AM: If i use the widget comments option i want it to be generally applied and taken away depending on the properties setting. I do not want to find out that somewhere it is not following the setting, then have to dig in the code and find out that is, because somebody put an undocumented override somewhere by default as happened the first time. Bird and google checkout is fine. I think how it is implemented now is fine. I hope i commented now enough? Regards, Hans On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote: Hans, Jacques gave some examples of where an override is currently used and why it is needed. Could you give us another reason besides i think an override is an overkill - like a reason based on a design issue or a real-world problem? -Adrian On 9/19/2011 7:55 AM, Hans Bakker wrote: I as sorry i do not see the problem here. as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. why? because i think an override is an overkill anyway Regards, Hans On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote: Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason.. In other word I guess Hans expect widget.verbose in the properties file to be false... Jacques From: Adrian Crumadrian.c...@sandglass-software.com Let's see if we can bring this to a happy ending. If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. Will that work for everyone? -Adrian On 9/15/2011 5:01 PM, Jacopo Cappellato wrote: I am going to feel bad if I don't add my 2 cents to this thread :-) I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of always rendering as html comments. As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always used this feature in a very rough way (enable all or disable all); however I can understand the we may want to avoid that (when widget.properties.enableBoundaryComments == false) the comments are enabled by passing a URL parameter to the screen. Kind regards, Jacopo On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote: Someone I work with suggested: I have to point out though that I kind of agree with the way David put it in that the false setting could have a priority, i.e. it's like in security permissions where deny has precedence over allow, so if you set it in widget.properties to false then you're sure comments will never be enabled anywhere... security-wise it makes sense despite the comment about qc... Maybe something like this? (compromise between the two) if (widget.properties.enableBoundaryComments ==
Re: widgetVerbose
Anne, Logging the settings is not necessary because the design is not that complicated. A setting in the widget.properties file is the default. That setting can be overridden in web.xml, and the setting in web.xml can be overridden in an individual screen widget by setting a value in the rendering context. So: properties file - web.xml - rendering context There is no need to go through code. If you enabled the widget comments in the properties file and the comments are not appearing in a particular web application, then check the web.xml file. If the comments are appearing in a web application but not in a particular screen, then check the screen widget xml file. It's very simple. We just have a couple of people who are trying to make it seem hard. -Adrian On 9/20/2011 12:56 AM, Anne wrote: If the main problem is not wanting to go through all the code to find where the comments are on/off, perhaps a solution would be log messages at startup saying which comments are turned on where? Then when anyone sees/doesn't see comments they do/don't want, they can look at the startup logs to see exactly what is on and off. And then no one will care as strongly about the details. I'm not familiar with this code, but I'd guess adding a logging statement where each relevant property is loaded wouldn't be difficult? Of course, if they are loaded lots of times all over the place, then it isn't that simple. In which case maybe something in webtools that reports what is on and off and where? Cheers, Anne. On 20 September 2011 02:02, BJ Freemanbjf...@free-man.net wrote: yes I understand. but a simple turn off all comments lets you work with that. but if you want to see what is generating that, then turn them all on. Like Hans said, I really don't want to have to go through code to find where it is turned off or on. Adrian Crum sent the following on 9/19/2011 8:56 AM: BJ, The original message of this thread points out why that approach does not work. If comments are defaulted to on, then there MUST be a way to turn them off for things like CSV output. -Adrian On 9/19/2011 4:39 PM, BJ Freeman wrote: +1 KISS one place to turn off and on. common sense says you use for development then you turn it off so there are no comments in the ouput. So there is not need to have the comments turned off at component level. Hans Bakker sent the following on 9/19/2011 2:14 AM: If i use the widget comments option i want it to be generally applied and taken away depending on the properties setting. I do not want to find out that somewhere it is not following the setting, then have to dig in the code and find out that is, because somebody put an undocumented override somewhere by default as happened the first time. Bird and google checkout is fine. I think how it is implemented now is fine. I hope i commented now enough? Regards, Hans On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote: Hans, Jacques gave some examples of where an override is currently used and why it is needed. Could you give us another reason besides i think an override is an overkill - like a reason based on a design issue or a real-world problem? -Adrian On 9/19/2011 7:55 AM, Hans Bakker wrote: I as sorry i do not see the problem here. as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. why? because i think an override is an overkill anyway Regards, Hans On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote: Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason.. In other word I guess Hans expect widget.verbose in the properties file to be false... Jacques From: Adrian Crumadrian.c...@sandglass-software.com Let's see if we can bring this to a happy ending. If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. Will that work for everyone? -Adrian On 9/15/2011 5:01 PM, Jacopo Cappellato wrote: I am going to feel bad if I don't add my 2 cents to this thread :-) I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of always rendering as html comments. As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always used this feature in a very rough way (enable all or disable all); however I can
Re: widgetVerbose
Thanks Adrian. I was just trying to work out a way everyone would get what they really wanted. Your precedence makes sense to me, and I'm not sure I understand others' concerns. But that doesn't mean I think they are unimportant, just that I haven't managed to understand yet. I was thinking their concern was that it was difficult to determine what's on/off and where, and hence thought I'd suggest a possible solution to that problem. Maybe I'm wrong. Cheers, Anne. On 20 September 2011 10:06, Adrian Crum adrian.c...@sandglass-software.com wrote: Anne, Logging the settings is not necessary because the design is not that complicated. A setting in the widget.properties file is the default. That setting can be overridden in web.xml, and the setting in web.xml can be overridden in an individual screen widget by setting a value in the rendering context. So: properties file - web.xml - rendering context There is no need to go through code. If you enabled the widget comments in the properties file and the comments are not appearing in a particular web application, then check the web.xml file. If the comments are appearing in a web application but not in a particular screen, then check the screen widget xml file. It's very simple. We just have a couple of people who are trying to make it seem hard. -Adrian On 9/20/2011 12:56 AM, Anne wrote: If the main problem is not wanting to go through all the code to find where the comments are on/off, perhaps a solution would be log messages at startup saying which comments are turned on where? Then when anyone sees/doesn't see comments they do/don't want, they can look at the startup logs to see exactly what is on and off. And then no one will care as strongly about the details. I'm not familiar with this code, but I'd guess adding a logging statement where each relevant property is loaded wouldn't be difficult? Of course, if they are loaded lots of times all over the place, then it isn't that simple. In which case maybe something in webtools that reports what is on and off and where? Cheers, Anne. On 20 September 2011 02:02, BJ Freemanbjf...@free-man.net wrote: yes I understand. but a simple turn off all comments lets you work with that. but if you want to see what is generating that, then turn them all on. Like Hans said, I really don't want to have to go through code to find where it is turned off or on. Adrian Crum sent the following on 9/19/2011 8:56 AM: BJ, The original message of this thread points out why that approach does not work. If comments are defaulted to on, then there MUST be a way to turn them off for things like CSV output. -Adrian On 9/19/2011 4:39 PM, BJ Freeman wrote: +1 KISS one place to turn off and on. common sense says you use for development then you turn it off so there are no comments in the ouput. So there is not need to have the comments turned off at component level. Hans Bakker sent the following on 9/19/2011 2:14 AM: If i use the widget comments option i want it to be generally applied and taken away depending on the properties setting. I do not want to find out that somewhere it is not following the setting, then have to dig in the code and find out that is, because somebody put an undocumented override somewhere by default as happened the first time. Bird and google checkout is fine. I think how it is implemented now is fine. I hope i commented now enough? Regards, Hans On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote: Hans, Jacques gave some examples of where an override is currently used and why it is needed. Could you give us another reason besides i think an override is an overkill - like a reason based on a design issue or a real-world problem? -Adrian On 9/19/2011 7:55 AM, Hans Bakker wrote: I as sorry i do not see the problem here. as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. why? because i think an override is an overkill anyway Regards, Hans On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote: Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason.. In other word I guess Hans expect widget.verbose in the properties file to be false... Jacques From: Adrian Crumadrian.c...@sandglass-software.com Let's see if we can bring this to a happy ending. If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the
Re: widgetVerbose
Anne, Your suggestions are appreciated. We're already making a mountain out of a molehill with this issue, and logging the setting would just add to the mountain. -Adrian On 9/20/2011 1:29 AM, Anne wrote: Thanks Adrian. I was just trying to work out a way everyone would get what they really wanted. Your precedence makes sense to me, and I'm not sure I understand others' concerns. But that doesn't mean I think they are unimportant, just that I haven't managed to understand yet. I was thinking their concern was that it was difficult to determine what's on/off and where, and hence thought I'd suggest a possible solution to that problem. Maybe I'm wrong. Cheers, Anne. On 20 September 2011 10:06, Adrian Crum adrian.c...@sandglass-software.com wrote: Anne, Logging the settings is not necessary because the design is not that complicated. A setting in the widget.properties file is the default. That setting can be overridden in web.xml, and the setting in web.xml can be overridden in an individual screen widget by setting a value in the rendering context. So: properties file - web.xml - rendering context There is no need to go through code. If you enabled the widget comments in the properties file and the comments are not appearing in a particular web application, then check the web.xml file. If the comments are appearing in a web application but not in a particular screen, then check the screen widget xml file. It's very simple. We just have a couple of people who are trying to make it seem hard. -Adrian On 9/20/2011 12:56 AM, Anne wrote: If the main problem is not wanting to go through all the code to find where the comments are on/off, perhaps a solution would be log messages at startup saying which comments are turned on where? Then when anyone sees/doesn't see comments they do/don't want, they can look at the startup logs to see exactly what is on and off. And then no one will care as strongly about the details. I'm not familiar with this code, but I'd guess adding a logging statement where each relevant property is loaded wouldn't be difficult? Of course, if they are loaded lots of times all over the place, then it isn't that simple. In which case maybe something in webtools that reports what is on and off and where? Cheers, Anne. On 20 September 2011 02:02, BJ Freemanbjf...@free-man.netwrote: yes I understand. but a simple turn off all comments lets you work with that. but if you want to see what is generating that, then turn them all on. Like Hans said, I really don't want to have to go through code to find where it is turned off or on. Adrian Crum sent the following on 9/19/2011 8:56 AM: BJ, The original message of this thread points out why that approach does not work. If comments are defaulted to on, then there MUST be a way to turn them off for things like CSV output. -Adrian On 9/19/2011 4:39 PM, BJ Freeman wrote: +1 KISS one place to turn off and on. common sense says you use for development then you turn it off so there are no comments in the ouput. So there is not need to have the comments turned off at component level. Hans Bakker sent the following on 9/19/2011 2:14 AM: If i use the widget comments option i want it to be generally applied and taken away depending on the properties setting. I do not want to find out that somewhere it is not following the setting, then have to dig in the code and find out that is, because somebody put an undocumented override somewhere by default as happened the first time. Bird and google checkout is fine. I think how it is implemented now is fine. I hope i commented now enough? Regards, Hans On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote: Hans, Jacques gave some examples of where an override is currently used and why it is needed. Could you give us another reason besides i think an override is an overkill - like a reason based on a design issue or a real-world problem? -Adrian On 9/19/2011 7:55 AM, Hans Bakker wrote: I as sorry i do not see the problem here. as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. why? because i think an override is an overkill anyway Regards, Hans On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote: Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason.. In other word I guess Hans expect widget.verbose in the properties file to be false... Jacques From: Adrian Crumadrian.c...@sandglass-software.com Let's see if we can bring this to a happy ending. If the widget.verbose setting in the properties file is false, then it overrides any other setting
Re: widgetVerbose
Thank you everyone for your patience and comments during this
discussion. I believe we are near a resolution.
From my perspective, this is where we stand:
1. I proposed the following design based on David's suggestion:
If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true, then it
follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.
2. Hans is willing to accept the design, as long as there are no
undocumented surprises where the setting is changed in web.xml files.
Some web applications that require the setting to be off even when the
default is on are okay.
3. I asked Hans for a confirmation that my understanding of his replies
is correct. He has not replied.
4. If there are no further objections, then we can proceed with
implementing the design.
-Adrian
On 9/19/2011 10:23 AM, Adrian Crum wrote:
Hans,
We can document the behavior in the properties file, and we have this
discussion on record to describe the behavior and the reason why it
was done that way. I believe those things will help avoid confusion in
the future.
So, can we implement the behavior I described? I believe you already
answered this question, but I am asking again just to be sure.
-Adrian
On 9/19/2011 10:14 AM, Hans Bakker wrote:
If i use the widget comments option i want it to be generally applied
and taken away depending on the properties setting. I do not want to
find out that somewhere it is not following the setting, then have to
dig in the code and find out that is, because somebody put an
undocumented override somewhere by default as happened the first time.
Bird and google checkout is fine.
I think how it is implemented now is fine. I hope i commented now
enough?
Regards,
Hans
On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote:
Hans,
Jacques gave some examples of where an override is currently used and
why it is needed. Could you give us another reason besides i think an
override is an overkill - like a reason based on a design issue or a
real-world problem?
-Adrian
On 9/19/2011 7:55 AM, Hans Bakker wrote:
I as sorry i do not see the problem here.
as long as the properties setting in the trunk will show or hide all
widget comments (so in the trunk NO override) then it is fine.
why? because i think an override is an overkill anyway
Regards,
Hans
On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote:
Yes, but I guess we will set widget.verbose in the properties file
to true (as we do for all defaults to be dev friendly). Will that
suit Hans? Else why do you Hans ask for now overriding in web.xml?
For instance what for Birt by defaut? Why not keeping the example
in example component commented out? Waht for testtools? Not sure
why it's false in googlecheckout but I guess there is a reason..
In other word I guess Hans expect widget.verbose in the properties
file to be false...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false,
then it overrides any other setting and all boundary comments are
shut off.
If the widget.verbose setting in the properties file is true,
then it follows the previous pattern, where true is the default, but
it can be overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments
should be output specific (i.e no output for CSV etc...) instead of
always rendering as html comments.
As regards the logic to determine if comments should be enabled
or not, I don't have a strong opinion because I have always used
this feature in a very rough way (enable all or disable all);
however I can understand the we may want to avoid that (when
widget.properties.enableBoundaryComments == false) the comments
are enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way
David put it in that the false setting could have a priority,
i.e. it's like in security permissions where deny has
precedence over allow, so if you set it in widget.properties to
false
then you're sure comments will never be enabled anywhere...
security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use
Re: widgetVerbose
Ok Adrian, at least for the third time: (five times in a different wording) what i wrote? as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. Regards, Hans On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote: Thank you everyone for your patience and comments during this discussion. I believe we are near a resolution. From my perspective, this is where we stand: 1. I proposed the following design based on David's suggestion: If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. 2. Hans is willing to accept the design, as long as there are no undocumented surprises where the setting is changed in web.xml files. Some web applications that require the setting to be off even when the default is on are okay. 3. I asked Hans for a confirmation that my understanding of his replies is correct. He has not replied. 4. If there are no further objections, then we can proceed with implementing the design. -Adrian On 9/19/2011 10:23 AM, Adrian Crum wrote: Hans, We can document the behavior in the properties file, and we have this discussion on record to describe the behavior and the reason why it was done that way. I believe those things will help avoid confusion in the future. So, can we implement the behavior I described? I believe you already answered this question, but I am asking again just to be sure. -Adrian On 9/19/2011 10:14 AM, Hans Bakker wrote: If i use the widget comments option i want it to be generally applied and taken away depending on the properties setting. I do not want to find out that somewhere it is not following the setting, then have to dig in the code and find out that is, because somebody put an undocumented override somewhere by default as happened the first time. Bird and google checkout is fine. I think how it is implemented now is fine. I hope i commented now enough? Regards, Hans On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote: Hans, Jacques gave some examples of where an override is currently used and why it is needed. Could you give us another reason besides i think an override is an overkill - like a reason based on a design issue or a real-world problem? -Adrian On 9/19/2011 7:55 AM, Hans Bakker wrote: I as sorry i do not see the problem here. as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. why? because i think an override is an overkill anyway Regards, Hans On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote: Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason.. In other word I guess Hans expect widget.verbose in the properties file to be false... Jacques From: Adrian Crumadrian.c...@sandglass-software.com Let's see if we can bring this to a happy ending. If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. Will that work for everyone? -Adrian On 9/15/2011 5:01 PM, Jacopo Cappellato wrote: I am going to feel bad if I don't add my 2 cents to this thread :-) I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of always rendering as html comments. As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always used this feature in a very rough way (enable all or disable all); however I can understand the we may want to avoid that (when widget.properties.enableBoundaryComments == false) the comments are enabled by passing a URL parameter to the screen. Kind regards, Jacopo On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote: Someone I work with suggested: I have to point out though that I kind of agree with the way David put it in that the false setting could have a priority, i.e. it's like in security permissions where deny has precedence
Re: widgetVerbose
Thank you Hans, but repeating your confusing replies does not make them any clearer. I need a simple yes or no answer: May we implement the design I proposed? -Adrian On 9/20/2011 2:17 AM, Hans Bakker wrote: Ok Adrian, at least for the third time: (five times in a different wording) what i wrote? as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. Regards, Hans On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote: Thank you everyone for your patience and comments during this discussion. I believe we are near a resolution. From my perspective, this is where we stand: 1. I proposed the following design based on David's suggestion: If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. 2. Hans is willing to accept the design, as long as there are no undocumented surprises where the setting is changed in web.xml files. Some web applications that require the setting to be off even when the default is on are okay. 3. I asked Hans for a confirmation that my understanding of his replies is correct. He has not replied. 4. If there are no further objections, then we can proceed with implementing the design. -Adrian On 9/19/2011 10:23 AM, Adrian Crum wrote: Hans, We can document the behavior in the properties file, and we have this discussion on record to describe the behavior and the reason why it was done that way. I believe those things will help avoid confusion in the future. So, can we implement the behavior I described? I believe you already answered this question, but I am asking again just to be sure. -Adrian On 9/19/2011 10:14 AM, Hans Bakker wrote: If i use the widget comments option i want it to be generally applied and taken away depending on the properties setting. I do not want to find out that somewhere it is not following the setting, then have to dig in the code and find out that is, because somebody put an undocumented override somewhere by default as happened the first time. Bird and google checkout is fine. I think how it is implemented now is fine. I hope i commented now enough? Regards, Hans On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote: Hans, Jacques gave some examples of where an override is currently used and why it is needed. Could you give us another reason besides i think an override is an overkill - like a reason based on a design issue or a real-world problem? -Adrian On 9/19/2011 7:55 AM, Hans Bakker wrote: I as sorry i do not see the problem here. as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. why? because i think an override is an overkill anyway Regards, Hans On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote: Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason.. In other word I guess Hans expect widget.verbose in the properties file to be false... Jacques From: Adrian Crumadrian.c...@sandglass-software.com Let's see if we can bring this to a happy ending. If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. Will that work for everyone? -Adrian On 9/15/2011 5:01 PM, Jacopo Cappellato wrote: I am going to feel bad if I don't add my 2 cents to this thread :-) I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of always rendering as html comments. As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always used this feature in a very rough way (enable all or disable all); however I can understand the we may want to avoid that (when widget.properties.enableBoundaryComments == false) the comments are enabled by passing a URL parameter to the screen. Kind regards, Jacopo On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote: Someone I work with suggested: I have to point out though that I kind of agree with the way David put it in that the false setting could have a priority, i.e. it's like in security permissions where deny has precedence
Re: widgetVerbose
Sorry my English Adrian, as usual, every change in the system you make as difficult as possible, technically you are very good and from that point of view happy to have you in the community, but communication and consideration of end users, no one is perfectso sure (that means YES) you can go ahead. Regards Hans On Tue, 2011-09-20 at 02:21 +0100, Adrian Crum wrote: Thank you Hans, but repeating your confusing replies does not make them any clearer. I need a simple yes or no answer: May we implement the design I proposed? -Adrian On 9/20/2011 2:17 AM, Hans Bakker wrote: Ok Adrian, at least for the third time: (five times in a different wording) what i wrote? as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. Regards, Hans On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote: Thank you everyone for your patience and comments during this discussion. I believe we are near a resolution. From my perspective, this is where we stand: 1. I proposed the following design based on David's suggestion: If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. 2. Hans is willing to accept the design, as long as there are no undocumented surprises where the setting is changed in web.xml files. Some web applications that require the setting to be off even when the default is on are okay. 3. I asked Hans for a confirmation that my understanding of his replies is correct. He has not replied. 4. If there are no further objections, then we can proceed with implementing the design. -Adrian On 9/19/2011 10:23 AM, Adrian Crum wrote: Hans, We can document the behavior in the properties file, and we have this discussion on record to describe the behavior and the reason why it was done that way. I believe those things will help avoid confusion in the future. So, can we implement the behavior I described? I believe you already answered this question, but I am asking again just to be sure. -Adrian On 9/19/2011 10:14 AM, Hans Bakker wrote: If i use the widget comments option i want it to be generally applied and taken away depending on the properties setting. I do not want to find out that somewhere it is not following the setting, then have to dig in the code and find out that is, because somebody put an undocumented override somewhere by default as happened the first time. Bird and google checkout is fine. I think how it is implemented now is fine. I hope i commented now enough? Regards, Hans On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote: Hans, Jacques gave some examples of where an override is currently used and why it is needed. Could you give us another reason besides i think an override is an overkill - like a reason based on a design issue or a real-world problem? -Adrian On 9/19/2011 7:55 AM, Hans Bakker wrote: I as sorry i do not see the problem here. as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. why? because i think an override is an overkill anyway Regards, Hans On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote: Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason.. In other word I guess Hans expect widget.verbose in the properties file to be false... Jacques From: Adrian Crumadrian.c...@sandglass-software.com Let's see if we can bring this to a happy ending. If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. Will that work for everyone? -Adrian On 9/15/2011 5:01 PM, Jacopo Cappellato wrote: I am going to feel bad if I don't add my 2 cents to this thread :-) I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of always rendering as html comments. As regards the logic to determine if comments should be enabled or not, I don't have a
Re: widgetVerbose
Thank you Hans. I will work on the proposed design and get it committed. If there are any issues with the commit, I hope we can discuss them here and not engage in a commit war. -Adrian On 9/20/2011 2:31 AM, Hans Bakker wrote: Sorry my English Adrian, as usual, every change in the system you make as difficult as possible, technically you are very good and from that point of view happy to have you in the community, but communication and consideration of end users, no one is perfectso sure (that means YES) you can go ahead. Regards Hans On Tue, 2011-09-20 at 02:21 +0100, Adrian Crum wrote: Thank you Hans, but repeating your confusing replies does not make them any clearer. I need a simple yes or no answer: May we implement the design I proposed? -Adrian On 9/20/2011 2:17 AM, Hans Bakker wrote: Ok Adrian, at least for the third time: (five times in a different wording) what i wrote? as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. Regards, Hans On Tue, 2011-09-20 at 02:10 +0100, Adrian Crum wrote: Thank you everyone for your patience and comments during this discussion. I believe we are near a resolution. From my perspective, this is where we stand: 1. I proposed the following design based on David's suggestion: If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. 2. Hans is willing to accept the design, as long as there are no undocumented surprises where the setting is changed in web.xml files. Some web applications that require the setting to be off even when the default is on are okay. 3. I asked Hans for a confirmation that my understanding of his replies is correct. He has not replied. 4. If there are no further objections, then we can proceed with implementing the design. -Adrian On 9/19/2011 10:23 AM, Adrian Crum wrote: Hans, We can document the behavior in the properties file, and we have this discussion on record to describe the behavior and the reason why it was done that way. I believe those things will help avoid confusion in the future. So, can we implement the behavior I described? I believe you already answered this question, but I am asking again just to be sure. -Adrian On 9/19/2011 10:14 AM, Hans Bakker wrote: If i use the widget comments option i want it to be generally applied and taken away depending on the properties setting. I do not want to find out that somewhere it is not following the setting, then have to dig in the code and find out that is, because somebody put an undocumented override somewhere by default as happened the first time. Bird and google checkout is fine. I think how it is implemented now is fine. I hope i commented now enough? Regards, Hans On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote: Hans, Jacques gave some examples of where an override is currently used and why it is needed. Could you give us another reason besides i think an override is an overkill - like a reason based on a design issue or a real-world problem? -Adrian On 9/19/2011 7:55 AM, Hans Bakker wrote: I as sorry i do not see the problem here. as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. why? because i think an override is an overkill anyway Regards, Hans On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote: Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason.. In other word I guess Hans expect widget.verbose in the properties file to be false... Jacques From: Adrian Crumadrian.c...@sandglass-software.com Let's see if we can bring this to a happy ending. If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. Will that work for everyone? -Adrian On 9/15/2011 5:01 PM, Jacopo Cappellato wrote: I am going to feel bad if I don't add my 2 cents to this thread :-) I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of always rendering as html comments. As regards the logic to determine if comments should be
Re: widgetVerbose
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 nocsv element and you have to
usehtml) element. No matter what widget.verbose is set to, there should never be
HTmL comments outputted for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because a user
might accidentally leave the comments enabled in production seems silly.
That is a user's QC problem, not a widget comment design problem.
-Adrian
+ 1
Bilgin
Re: widgetVerbose
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 nocsv element
and you have to usehtml) element. No matter what widget.verbose is set
to, there should never be HTmL comments outputted for csv. so this only
addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen
intensiven Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because a
user
might accidentally leave the comments enabled in production seems silly.
That is a user's QC problem, not a widget comment design problem.
-Adrian
+ 1
Bilgin
--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Alternative ofbiz website: http://www.ofbiz.info
http://www.antwebsystems.com : Quality services for competitive rates.
Re: widgetVerbose
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 nocsv element and you have to
usehtml) element. No matter what widget.verbose is set to, there should never be
HTmL comments outputted for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because a user
might accidentally leave the comments enabled in production seems silly.
That is a user's QC problem, not a widget comment design problem.
-Adrian
+ 1
Bilgin
Re: widgetVerbose
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 nocsv
element and you have to usehtml) element. No matter what
widget.verbose is set to, there should never be HTmL comments outputted
for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand
B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen
intensiven Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because
a user
might accidentally leave the comments enabled in production seems
silly.
That is a user's QC problem, not a widget comment design problem.
-Adrian
+ 1
Bilgin
--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Alternative ofbiz website: http://www.ofbiz.info
http://www.antwebsystems.com : Quality services for competitive rates.
Re: widgetVerbose
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 nocsvelement and you have to
usehtml) element. No matter what widget.verbose is set to, there should never be
HTmL comments outputted for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.comwrote:
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
Re: widgetVerbose
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 nocsv
element and you have to usehtml) element. No matter what
widget.verbose is set to, there should never be HTmL comments outputted
for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld,
Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand
B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen
intensiven Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryambibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.comwrote:
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
smime.p7s
Description: S
Re: widgetVerbose
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put it in that the false setting could have a priority, i.e.
it's like in security permissions where deny has precedence over allow, so if you set it in widget.properties to false then you're
sure comments will never be enabled anywhere... security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding settings only
for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what
do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that HTML comments are outputted for CSV (because there's no
csv element and you have to use html) element. No matter what widget.verbose is set to, there should never be HTmL comments
outputted for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryam bibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because a user
might accidentally leave the comments enabled in production seems silly.
That is a user's QC problem, not a widget comment design problem.
-Adrian
+ 1
Bilgin
Re: widgetVerbose
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output
specific (i.e no output for CSV etc...) instead of always rendering as html
comments.
As regards the logic to determine if comments should be enabled or not, I don't
have a strong opinion because I have always used this feature in a very rough
way (enable all or disable all); however I can understand the we may want to
avoid that (when widget.properties.enableBoundaryComments == false) the
comments are enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put it in
that the false setting could have a priority, i.e. it's like in security
permissions where deny has precedence over allow, so if you set it in
widget.properties to false then you're sure comments will never be enabled
anywhere... security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding settings
only for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to me,
what do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that
HTML comments are outputted for CSV (because there's no csv element and you
have to use html) element. No matter what widget.verbose is set to, there
should never be HTmL comments outputted for csv. so this only addresses half
the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryam bibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because a user
might accidentally leave the comments enabled in production seems silly.
That is a user's QC problem, not a widget comment design problem.
-Adrian
+ 1
Bilgin
Re: widgetVerbose
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: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen
intensiven Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryam bibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because
a user
might accidentally leave the comments enabled in production seems
silly.
That is a user's QC problem, not a widget comment design problem.
-Adrian
+ 1
Bilgin
Re: widgetVerbose
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
Re: widgetVerbose
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: Thanks Scott - those are my feelings exactly. I like the way the design worked previously, and changing it because a user might accidentally leave the comments enabled in production seems silly. That is a user's QC problem, not a widget comment design problem. -Adrian + 1 Bilgin
Re: widgetVerbose
+1 Dimitri Unruh Consultant AEW Lynx-Consulting GmbH Johanniskirchplatz 6 33615 Bielefeld Deutschland Fon: +49 521 5247-0 Fax: +49 521 5247-250 Mobil: +49 160 90 57 55 13 Company and Management Headquarters: Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de Court Registration: Amtsgericht Bielefeld HRB 35946 Chief Executive Officers: Karsten Noss, Dirk Osterkamp http://www.lynx.de/haftungsausschluss Wir laden Sie herzlich ein: DSAG-Jahreskongress Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01 Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven Informations- und Erfahrungsaustausch rund um das Thema Mobility! Am 13.09.2011 um 14:35 schrieb Bilgin Ibryam bibr...@gmail.com: On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: Thanks Scott - those are my feelings exactly. I like the way the design worked previously, and changing it because a user might accidentally leave the comments enabled in production seems silly. That is a user's QC problem, not a widget comment design problem. -Adrian + 1 Bilgin
Fw: widgetVerbose
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 htmlhtml-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
Re: Fw: widgetVerbose
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 htmlhtml-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
Re: widgetVerbose
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 htmlhtml-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
Re: widgetVerbose
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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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
Re: widgetVerbose
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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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
Re: widgetVerbose
Thanks Adrian, I understand what you're getting at exactly now. Yes, this is frustrating isn't it, and this pattern seems to come up over and over. That's why I like the moderated community approach better (as opposed to the Apache way), and I guess you know my thoughts and approach on that based on my recent efforts… Still, I suppose that by the Apache way we should vote on this and consider the results binding, and make the corresponding changes. If someone goes against that vote result, then I'm not sure what the Apache way is… i.e. what do you do about a commit war? I don't know. -David On Sep 12, 2011, at 12:02 PM, 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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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
Re: widgetVerbose
Maybe a vote is in order. I am not going to initiate one because I am the author of the original code, so I feel like I am disqualified. -Adrian On 9/12/2011 8:13 PM, David E Jones wrote: Thanks Adrian, I understand what you're getting at exactly now. Yes, this is frustrating isn't it, and this pattern seems to come up over and over. That's why I like the moderated community approach better (as opposed to the Apache way), and I guess you know my thoughts and approach on that based on my recent efforts… Still, I suppose that by the Apache way we should vote on this and consider the results binding, and make the corresponding changes. If someone goes against that vote result, then I'm not sure what the Apache way is… i.e. what do you do about a commit war? I don't know. -David On Sep 12, 2011, at 12:02 PM, 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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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
Re: widgetVerbose
I don't think you should feel disqualified because you wrote the right code intially! Hans has an explanation, but democracy is majority. And Apache way is vote and majority in such cases. Unfortunately there are no other best ways than a vote. Now, as David remarked, last time we felt like the United Nations in some conflicts: you need a respected police or army to make the law respected... What I don't understand is why Hans can't keep his changes for himself to let all the others happy (at least Adrian, Scott, David and I so far...) Jacques From: Adrian Crum adrian.c...@sandglass-software.com Maybe a vote is in order. I am not going to initiate one because I am the author of the original code, so I feel like I am disqualified. -Adrian On 9/12/2011 8:13 PM, David E Jones wrote: Thanks Adrian, I understand what you're getting at exactly now. Yes, this is frustrating isn't it, and this pattern seems to come up over and over. That's why I like the moderated community approach better (as opposed to the Apache way), and I guess you know my thoughts and approach on that based on my recent efforts… Still, I suppose that by the Apache way we should vote on this and consider the results binding, and make the corresponding changes. If someone goes against that vote result, then I'm not sure what the Apache way is… i.e. what do you do about a commit war? I don't know. -David On Sep 12, 2011, at 12:02 PM, 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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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
Re: widgetVerbose
I have notice quite different coding styles that just does not fit one person committing code from Hans account. Maybe getting each an account would better clarify who is committing what. Jacques Le Roux sent the following on 9/12/2011 1:03 PM: I don't think you should feel disqualified because you wrote the right code intially! Hans has an explanation, but democracy is majority. And Apache way is vote and majority in such cases. Unfortunately there are no other best ways than a vote. Now, as David remarked, last time we felt like the United Nations in some conflicts: you need a respected police or army to make the law respected... What I don't understand is why Hans can't keep his changes for himself to let all the others happy (at least Adrian, Scott, David and I so far...) Jacques From: Adrian Crum adrian.c...@sandglass-software.com Maybe a vote is in order. I am not going to initiate one because I am the author of the original code, so I feel like I am disqualified. -Adrian On 9/12/2011 8:13 PM, David E Jones wrote: Thanks Adrian, I understand what you're getting at exactly now. Yes, this is frustrating isn't it, and this pattern seems to come up over and over. That's why I like the moderated community approach better (as opposed to the Apache way), and I guess you know my thoughts and approach on that based on my recent efforts… Still, I suppose that by the Apache way we should vote on this and consider the results binding, and make the corresponding changes. If someone goes against that vote result, then I'm not sure what the Apache way is… i.e. what do you do about a commit war? I don't know. -David On Sep 12, 2011, at 12:02 PM, 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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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
Re: widgetVerbose
There is an Apache way for that also: http://www.apache.org/dev/committers.html. And a related OFBiz way https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices Hans is simply committing work from his team. As long as he reviews and amend/fix the code, there is nothing we can say about it. Some complain that code quality has lowered for some time. But this is not only due to Hans's commits (committing contibutions is not an easy job). My opinion on this is as long as you improve your code, there is nothing wrong in committing lower quality code (not bad or wrong code of course). Of course it should not break and make wrong logic/business asumptions... Everybody has the right to learn... Sometimes it's the hard way... Are we not here to share? This is my own opinion, not the PMC of course... Jacques From: BJ Freeman bjf...@free-man.net I have notice quite different coding styles that just does not fit one person committing code from Hans account. Maybe getting each an account would better clarify who is committing what. Jacques Le Roux sent the following on 9/12/2011 1:03 PM: I don't think you should feel disqualified because you wrote the right code intially! Hans has an explanation, but democracy is majority. And Apache way is vote and majority in such cases. Unfortunately there are no other best ways than a vote. Now, as David remarked, last time we felt like the United Nations in some conflicts: you need a respected police or army to make the law respected... What I don't understand is why Hans can't keep his changes for himself to let all the others happy (at least Adrian, Scott, David and I so far...) Jacques From: Adrian Crum adrian.c...@sandglass-software.com Maybe a vote is in order. I am not going to initiate one because I am the author of the original code, so I feel like I am disqualified. -Adrian On 9/12/2011 8:13 PM, David E Jones wrote: Thanks Adrian, I understand what you're getting at exactly now. Yes, this is frustrating isn't it, and this pattern seems to come up over and over. That's why I like the moderated community approach better (as opposed to the Apache way), and I guess you know my thoughts and approach on that based on my recent efforts… Still, I suppose that by the Apache way we should vote on this and consider the results binding, and make the corresponding changes. If someone goes against that vote result, then I'm not sure what the Apache way is… i.e. what do you do about a commit war? I don't know. -David On Sep 12, 2011, at 12:02 PM, 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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could
Re: widgetVerbose
I personally am aware of how hard it is to reviews everyone code before being accepted for a commit. So I adopted a design review from the complete team. Everyone had to review and sign off n the code before it is committed. I know that is not possible in ofbiz commit framework, however in a private company it is and takes care of all that you expressed. Jacques Le Roux sent the following on 9/12/2011 1:59 PM: There is an Apache way for that also: http://www.apache.org/dev/committers.html. And a related OFBiz way https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices Hans is simply committing work from his team. As long as he reviews and amend/fix the code, there is nothing we can say about it. Some complain that code quality has lowered for some time. But this is not only due to Hans's commits (committing contibutions is not an easy job). My opinion on this is as long as you improve your code, there is nothing wrong in committing lower quality code (not bad or wrong code of course). Of course it should not break and make wrong logic/business asumptions... Everybody has the right to learn... Sometimes it's the hard way... Are we not here to share? This is my own opinion, not the PMC of course... Jacques From: BJ Freeman bjf...@free-man.net I have notice quite different coding styles that just does not fit one person committing code from Hans account. Maybe getting each an account would better clarify who is committing what. Jacques Le Roux sent the following on 9/12/2011 1:03 PM: I don't think you should feel disqualified because you wrote the right code intially! Hans has an explanation, but democracy is majority. And Apache way is vote and majority in such cases. Unfortunately there are no other best ways than a vote. Now, as David remarked, last time we felt like the United Nations in some conflicts: you need a respected police or army to make the law respected... What I don't understand is why Hans can't keep his changes for himself to let all the others happy (at least Adrian, Scott, David and I so far...) Jacques From: Adrian Crum adrian.c...@sandglass-software.com Maybe a vote is in order. I am not going to initiate one because I am the author of the original code, so I feel like I am disqualified. -Adrian On 9/12/2011 8:13 PM, David E Jones wrote: Thanks Adrian, I understand what you're getting at exactly now. Yes, this is frustrating isn't it, and this pattern seems to come up over and over. That's why I like the moderated community approach better (as opposed to the Apache way), and I guess you know my thoughts and approach on that based on my recent efforts… Still, I suppose that by the Apache way we should vote on this and consider the results binding, and make the corresponding changes. If someone goes against that vote result, then I'm not sure what the Apache way is… i.e. what do you do about a commit war? I don't know. -David On Sep 12, 2011, at 12:02 PM, 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
Re: widgetVerbose
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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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.
Re: widgetVerbose
Are you referring to the setting that was in the Example component web.xml file? If yes, then there was agreement that the setting was causing confusion and it was commented out. -Adrian On 9/13/2011 1:03 AM, 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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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
Re: widgetVerbose
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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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.
Re: widgetVerbose
exactly i was saying all along (and as it is now), but i am always in for a compromise... Hans On Mon, 2011-09-12 at 18:22 -0700, 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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Alternative ofbiz website: http://www.ofbiz.info http://www.antwebsystems.com : Quality services for competitive rates.
Re: widgetVerbose
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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv 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
Re: widgetVerbose
the way I read Davids post was if (widgetVerbose property == true) then the control is in the web.xml or parramtters. if non of them turn it off then then the comments will show. if (widgetVerbose property == false) then no matter what the web.xml or paramters are set there is no comments. Adrian Crum sent the following on 9/12/2011 6:45 PM: 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 usinghtmlhtml-template /, but this always adds HTML comments even if the output is CSV (see HtmlWidget class). Maybe we could introduce acsv element or something like that? Anyway, both of those problems combined mean
Re: widgetVerbose
No, that is not what he said. If the properties file setting is true, then the setting is ignored and comments are off by default - unless they are explicitly turned on in a URL parameter or web.xml file. -Adrian On 9/13/2011 4:08 AM, BJ Freeman wrote: the way I read Davids post was if (widgetVerbose property == true) then the control is in the web.xml or parramtters. if non of them turn it off then then the comments will show. if (widgetVerbose property == false) then no matter what the web.xml or paramters are set there is no comments. Adrian Crum sent the following on 9/12/2011 6:45 PM: 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 usinghtmlhtml-template /, but this always adds HTML
Re: widgetVerbose
There was an old thread about this with a few complaints, but it looks like it stands. Maybe more discussion and/or a commit war is in order? ;) -David On Aug 30, 2011, at 9:15 PM, 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? 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 htmlhtml-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
Re: widgetVerbose
It's strange actually, I thought I had silently fixed this a few months ago. The precedence should be: context - web.xml - widget.properties Jacques, have you tried using the screencsv view handler for the csv problem? Regards Scott On 31/08/2011, at 6:34 PM, David E Jones wrote: There was an old thread about this with a few complaints, but it looks like it stands. Maybe more discussion and/or a commit war is in order? ;) -David On Aug 30, 2011, at 9:15 PM, 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? 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 htmlhtml-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 smime.p7s Description: S/MIME cryptographic signature
Re: widgetVerbose
On 8/31/2011 4:15 AM, 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? The widget.verbose setting worked correctly originally, but a committer didn't understand its behavior and changed it: http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r961684-ofbiz-trunk-framework-widget-src-org-ofbiz-widget-ModelWidget-java-tt2282062.html#none Now the setting is unusable. 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 htmlhtml-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? If the widget.verbose code was put back to the way it was, then you would be able to turn off the boundary comments when rendering csv. 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. -Adrian
Re: widgetVerbose
On 31/08/2011, at 8:02 PM, Scott Gray wrote: It's strange actually, I thought I had silently fixed this a few months ago. The precedence should be: context - web.xml - widget.properties Jacques, have you tried using the screencsv view handler for the csv problem? Sorry, just noticed you answered this in your original email. Regards Scott On 31/08/2011, at 6:34 PM, David E Jones wrote: There was an old thread about this with a few complaints, but it looks like it stands. Maybe more discussion and/or a commit war is in order? ;) -David On Aug 30, 2011, at 9:15 PM, 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? 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 htmlhtml-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 smime.p7s Description: S/MIME cryptographic signature
widgetVerbose
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? 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 htmlhtml-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
