Thanks Adrian. I was just trying to work out a way everyone would get
what they really wanted.
Your precedence makes sense to me, and I'm not sure I understand
others' concerns. But that doesn't mean I think they are unimportant,
just that I haven't managed to understand yet.
I was thinking their concern was that it was difficult to determine
what's on/off and where, and hence thought I'd suggest a possible
solution to that problem. Maybe I'm wrong.
Cheers,
Anne.
On 20 September 2011 10:06, Adrian Crum
<adrian.c...@sandglass-software.com> wrote:
> Anne,
>
> Logging the settings is not necessary because the design is not that
> complicated. A setting in the widget.properties file is the default. That
> setting can be overridden in web.xml, and the setting in web.xml can be
> overridden in an individual screen widget by setting a value in the
> rendering context. So:
>
> properties file -> web.xml -> rendering context
>
> There is no need to go through code. If you enabled the widget comments in
> the properties file and the comments are not appearing in a particular web
> application, then check the web.xml file. If the comments are appearing in a
> web application but not in a particular screen, then check the screen widget
> xml file. It's very simple. We just have a couple of people who are trying
> to make it seem hard.
>
> -Adrian
>
> On 9/20/2011 12:56 AM, Anne wrote:
>>
>> If the main problem is not wanting to go through all the code to find
>> where the comments are on/off, perhaps a solution would be log
>> messages at startup saying which comments are turned on where? Then
>> when anyone sees/doesn't see comments they do/don't want, they can
>> look at the startup logs to see exactly what is on and off. And then
>> no one will care as strongly about the details.
>>
>> I'm not familiar with this code, but I'd guess adding a logging
>> statement where each relevant property is loaded wouldn't be
>> difficult? Of course, if they are loaded lots of times all over the
>> place, then it isn't that simple.
>>
>> In which case maybe something in webtools that reports what is on and
>> off and where?
>>
>> Cheers,
>> Anne.
>>
>> On 20 September 2011 02:02, BJ Freeman<bjf...@free-man.net> wrote:
>>>
>>> yes I understand. but a simple turn off all comments lets you work with
>>> that. but if you want to see what is generating that, then turn them all
>>> on.
>>> Like Hans said, I really don't want to have to go through code to find
>>> where it is turned off or on.
>>>
>>> Adrian Crum sent the following on 9/19/2011 8:56 AM:
>>>>
>>>> BJ,
>>>>
>>>> The original message of this thread points out why that approach does
>>>> not work. If comments are defaulted to on, then there MUST be a way to
>>>> turn them off for things like CSV output.
>>>>
>>>> -Adrian
>>>>
>>>> On 9/19/2011 4:39 PM, BJ Freeman wrote:
>>>>>
>>>>> +1
>>>>> KISS
>>>>> one place to turn off and on. common sense says you use for development
>>>>> then you turn it off so there are no comments in the ouput.
>>>>> So there is not need to have the comments turned off at component
>>>>> level.
>>>>>
>>>>>
>>>>> Hans Bakker sent the following on 9/19/2011 2:14 AM:
>>>>>>
>>>>>> 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
>>
>>
>
--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sa...@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
