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 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
>
>
--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Alternative ofbiz website: http://www.ofbiz.info
http://www.antwebsystems.com : Quality services for competitive rates.
