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