Let's see if we can bring this to a happy ending.
If the widget.verbose setting in the properties file is false, then it
overrides any other setting and all boundary comments are shut off.
If the widget.verbose setting in the properties file is true, then it
follows the previous pattern, where true is the default, but it can be
overridden in web.xml and in the context Map.
Will that work for everyone?
-Adrian
On 9/15/2011 5:01 PM, Jacopo Cappellato wrote:
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output
specific (i.e no output for CSV etc...) instead of always rendering as html
comments.
As regards the logic to determine if comments should be enabled or not, I don't
have a strong opinion because I have always used this feature in a very rough
way (enable all or disable all); however I can understand the we may want to
avoid that (when widget.properties.enableBoundaryComments == false) the
comments are enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put it in that the
"false" setting could have a priority, i.e. it's like in security permissions where
"deny" has precedence over allow, so if you set it in widget.properties to false then
you're sure comments will never be enabled anywhere... security-wise it makes sense despite the
comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding settings only
for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to me, what
do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that HTML comments
are outputted for CSV (because there's no<csv> element and you have to
use<html>) element. No matter what widget.verbose is set to, there should never be
HTmL comments outputted for csv. so this only addresses half the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb "Bilgin Ibryam"<bibr...@gmail.com>:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
<adrian.c...@sandglass-software.com> wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because a user
might accidentally leave the comments enabled in production seems silly.
That is a user's QC problem, not a widget comment design problem.
-Adrian
+ 1
Bilgin
