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