Based on this I'm actually reconsidering my position, however the current implementation is still not adequate.
It sounds like the goal for the widget.properties is to make it easy to go into production and make sure that no boundary comments/etc are added anywhere in the system. To do that effectively you need a single setting for the whole system, and that setting should override everything else (i.e. not even allow for a parameter to be manually added which may expose implementation details that you want to keep hidden). For that purpose a property would make sense, but the logic has to be carefully done (not the shallow logic that has been discussed so far). It would need to be something like: if (widgetVerbose property == false) then don't show else if (widgetVerbose parameter (using default OFBiz parameters Map, takes into account both URL parameters and web.xml context parameters) == true) then show else don't show. In other words, if the widget.properties setting is false, then never show boundary comments. Otherwise, ignore it and use the parameters value if true, and overall default to false. Wow, is this really that hard? -David On Sep 12, 2011, at 5:03 PM, Hans Bakker wrote: > As i wrote before i am fine with this if in the trunk the setting of > widget.properties is not overridden by default in web.xml for some > component what was the case originally. > > Regards, > Hans > > On Mon, 2011-09-12 at 20:02 +0100, Adrian Crum wrote: >> David, >> >> Keep in mind that the original design is one that you participated in. >> The agreement on the setting precedence in the original Jira issue was this: >> >> widget.properties -> web.xml -> URL parameters >> >> where widget.properties is the global default, which can be overridden >> by a setting in web.xml, which can be overridden by screen widgets or >> scripts or whatever (via the current context Map). >> >> The design worked great. Then Hans changed it due to a misunderstanding >> of how the design works. Despite repeated explanations of how the design >> works, and requests from three PMC members to revert his change, he >> refused to change it and threatened the community with a commit war. >> Since then we have had a number of issues reported on the mailing list >> describing how his change makes the setting unusable. >> >> It amazes me that a single -1 vote vetoes a change in the Apache >> community, but three -1 votes from PMC members can't revert this obvious >> break in software design. >> >> -Adrian >> >> On 9/12/2011 7:24 PM, Adrian Crum wrote: >>> No. The approach suggested by (and committed by) Hans is that the >>> setting in the widget.properties file overrides any other setting. >>> >>> -Adrian >>> >>> On 9/12/2011 6:19 PM, David E Jones wrote: >>>> No one agrees with which approach? The approach that if you pass a >>>> widgetVerbose=true HTTP parameter that it should override the >>>> widget.properties setting? I agree with that approach… >>>> >>>> -David >>>> >>>> >>>> On Sep 12, 2011, at 6:59 AM, Adrian Crum wrote: >>>> >>>>> That's the problem - no one agrees with that approach. >>>>> >>>>> -Adrian >>>>> >>>>> On 9/12/2011 1:53 PM, Jacques Le Roux wrote: >>>>>> I think I forgot to forward Hans's answer >>>>>> >>>>>> Jacques >>>>>> >>>>>> Hans Bakker wrote: >>>>>>> On Wed, 2011-08-31 at 05:15 +0200, Jacques Le Roux wrote: >>>>>>>> widget.properties's widget.verbose setting has precedence over >>>>>>>> web.xml's widgetVerbose setting. So you can't use >>>>>>>> parameters.widgetVerbose to override widget.verbose to false. Is >>>>>>>> ModelWidget.widgetBoundaryCommentsEnabled() written this way for >>>>>>>> some reasons? >>>>>>> there was a lengthly discussion of this. As long as by default the >>>>>>> properties file is not overridden in web.xml is fine either way. >>>>>>> >>>>>>> >>>>>>>> Another issue is that these HTML boundary comments get outputted >>>>>>>> even though the view handler is set to "screencsv". In the >>>>>>>> widget-screen.xsd, the only way to invoke a template to produce >>>>>>>> CSV is using<html><html-template />, but this always adds HTML >>>>>>>> comments even if the output is CSV (see HtmlWidget class). Maybe >>>>>>>> we could introduce a<csv> element or something like that? >>>>>>>> >>>>>>>> Anyway, both of those problems combined mean that there are no >>>>>>>> apparent clean ways to remove the HTML "template begin/end" >>>>>>>> boundary comments from the CSV output if you try to draw it with >>>>>>>> an *.ftl template. A workaround kludge for now is to invoke >>>>>>>> the FTL manually through a Groovy script. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Jacques >>>>>> > > -- > Ofbiz on twitter: http://twitter.com/apache_ofbiz > Alternative ofbiz website: http://www.ofbiz.info > http://www.antwebsystems.com : Quality services for competitive rates. >
