I can think of one.
adding new components to a production site and not wanting to activated for the whole application.

Hans Bakker sent the following on 7/8/2010 11:33 PM:
Adrian,

can you please give us the business reason why you want the widget
properties setting via widgets.properties and web.xml as you implemented
it?

i really cannot see the benefits from a business point of view. The
disadvantages I already gave you.

Regards,
Hans



On Thu, 2010-07-08 at 23:04 -0700, Adrian Crum wrote:
Exactly! That's what I have been trying to say all along.

If Hans copied the Example component to create a new project, and the HTML 
comments were turned off in the Example component, then that doesn't mean there 
was a bug in the screen widgets. Instead, there was a problem in the settings 
in Hans' local copy.

If we want to turn on HTML comments in the Example component, then fine - let's 
discuss that. But why cripple the entire widget HTML comments feature in the 
process?

Btw, I noticed the resources component (which I believe generates new 
components) has widget comments turned off. That should be changed so they are 
on by default.

-Adrian


--- On Thu, 7/8/10, David E Jones<d...@me.com>  wrote:

From: David E Jones<d...@me.com>
Subject: Re: svn commit: r961684 - 
/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/ModelWidget.java
To: dev@ofbiz.apache.org
Date: Thursday, July 8, 2010, 10:52 PM

Just because you are fine with how it works doesn't mean
others are fine with it, which is usually the reason a
discussion starts and discovering such differences and
exploring possible resolutions is the point of discussions.

For my part, getting back to the issue, I also noticed that
the widget demarcation comments were no longer on by default
and I found it somewhat annoying. I don't think that the
changes Hans made are the right way to go. In fact, I think
how it worked before the round of changes to this that were
done before the changes Hans made was the way to go, ie:
like most things in OFBiz a default of a more
developer-friendly mode (the demarcation comments on) with a
configuration option to make it more production-friendly
(demarcation comments off).

-David


On Jul 8, 2010, at 11:45 PM, Adrian Crum wrote:

David,

You are missing the point - there was no issue. The
code worked fine.

I *have* addressed the issue. The correct behavior as
designed was detailed in my first reply. If anyone needs
further information they can check the commit logs and the
related Jira issue.

Hans had a misconfigured local copy, and he didn't
understand why it wasn't working the way it should. Instead
of asking for help on the mailing list, he arbitrarily
changed the trunk. If anyone else had done the same thing
there would be a similar reaction from the community.

Hans just admitted he made a mistake in his local
copy. Why should the trunk change to fix a mistake in
someone's local copy?

If Hans wants to change the design, then that's fine -
lets discuss that. But in the meantime the trunk is broken.
Hans broke it. I've tried to reason with him and asked him
to unbreak it.

What is so hard to understand about that?

-Adrian


--- On Thu, 7/8/10, David E Jones<d...@me.com>
wrote:

From: David E Jones<d...@me.com>
Subject: Re: svn commit: r961684 -
/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/ModelWidget.java
To: dev@ofbiz.apache.org
Date: Thursday, July 8, 2010, 10:32 PM

Adrian,

I hate to say it, but it seems like these messages
from
Hans are presenting the issue and attempting to
initiate a
discussion on the best way to go forward, and your
messages
are not discussing the issue and instead appealing
to some
sort of reason to not change how things are at
all.

This doesn't seem to be a two-way cooperation, so
who is it
that you want Hans to cooperate with?

-David


On Jul 8, 2010, at 9:58 PM, Adrian Crum wrote:

Hans,

There was no need for a compromise because
there was
no problem to begin with.

You just admitted the problem you were
experiencing
was due to a misconfiguration in your local copy.
Your
solution to that misconfiguration was to change
the trunk.
The trunk was not the problem - the problem was in
your
local copy.

Your changes broke the trunk. Please un-break
it.

If you revert your changes and properly
configure your
local copy, then everything will work as you
expect it to.

Please learn to cooperate. We are a community
of peers
and things will go smoother if you learn to follow
advice.

-Adrian


--- On Thu, 7/8/10, Hans Bakker<mailingl...@antwebsystems.com>
wrote:

From: Hans Bakker<mailingl...@antwebsystems.com>
Subject: Re: svn commit: r961684 -

/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/ModelWidget.java
To: dev@ofbiz.apache.org
Date: Thursday, July 8, 2010, 8:33 PM
Adrian,

what i proposed to you was a compromise.
You seem
to only
accept your
way, as happened many times in the past.

therefore i am not in for compromises any
more. I
would
like you to
remove the context code which enables the
override
in the
web.xml. It
makes the system unnecessarily complicated
for a
feature i
see no use.

It also causes to prohibit widgets
comments in the
example
component
which should show comments by default to
follow
the
principle to show
all possibilities in the system

Regards,
Hans

On Thu, 2010-07-08 at 20:00 -0700, Adrian
Crum
wrote:
Hans,

It's good that you took the time to
understand
the
problem.

What would be acceptable is to revert
the
changes you
made so the original behavior is restored.
Your
first commit
tried to fix something that wasn't broken,
and
your second
commit disables a demonstration of how the
widget
comments
can be controlled.

-Adrian

--- On Thu, 7/8/10, Hans Bakker<mailingl...@antwebsystems.com>
wrote:

From: Hans Bakker<mailingl...@antwebsystems.com>
Subject: Re: svn commit: r961684
-


/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/ModelWidget.java
To: dev@ofbiz.apache.org
Date: Thursday, July 8, 2010, 7:35
PM
Ok this is what happened:

I upgraded ofbiz from about 3-4
weeks ago.
Some
time ago i
created a new
component in hot deploy using the
web.xml
from
the example
component. I
see the widget comments are not
generated.
I
check
widget.properties and
see the parameter is set to true.
I used
this
feature
before and never
had a problem. I see that in
widgetBoundaryCommentsEnabled
class the
'context stuff' is changing true
to
false.

I not really see the benefit of
this code,
why
would
somebody want to
change this setting by the
context
content?
However, as
long as the
parameter in widget properties
works, then
i am
fine. So i
made the
change that this parameter can
only be
overridden
if the
widget comments
are switched of.

I now see that the comments in
the
example
component are
switched off in
web.xml? I also do not understand
this,
especially the
example component
should show comments?

I avoid this confusion in the
future I
added a
comment in
widget.properties that only
'false' can
be
overridden and
commented out
the code in web.xml of the
example
component.

I expect this should be acceptable
to
everybody?

Regards,
Hans



On Fri, 2010-07-09 at 00:28 +1200,
Scott
Gray
wrote:
Hi Hans,

Two points:
1.  Calm down, this is
just a
discussion.
Telling Adrian to look at the code
is
perfectly
valid,
getting mad and making threats is
not
2.  You're not the first
to
mention it
but I
don't know where this idea of a
veto came
from,
it doesn't
exist.  When required, the
PMC as a
group
can make
binding decisions but not
individuals.

Regards
Scott

On 9/07/2010, at 12:17 AM,
Hans
Bakker
wrote:

please check the code
before you
comment?

i changed it because the
comments
were
not shown
by default anymore as
was originally.

If you go that far , i
will go so
far
and will
use my veto and revert
the code that added this
context
stuff?
'true' in
the properties file
should always show the
widgets
comments
irrespective of the context.

no wonder there aren't
any
significant
changes in
the last few
months ....

Regards,
Hans


On Thu, 2010-07-08 at
04:47
-0700,
Adrian Crum
wrote:
Then you should change
the
description, not
the code. The intended behavior
is:

The properties setting
is the
default, it can
be overridden in the web.xml file
(application-wide
setting), or in the context
(screen-specific
setting).

-Adrian

--- On Thu, 7/8/10,
Hans
Bakker
<mailingl...@antwebsystems.com>
wrote:

From: Hans Bakker
<mailingl...@antwebsystems.com>
Subject: Re: svn
commit:
r961684 -



/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/ModelWidget.java
To: dev@ofbiz.apache.org
Date: Thursday,
July 8,
2010,
3:13 AM
I agree with what
the
description of
the code says at
the top.

your setting makes
that
the
widget.verbose by default is
false and the
messages are not
shown.

Regards,
Hans

P.S. i missed the
last
comments, which
one?

On Thu, 2010-07-08
at
21:54
+1200, Scott
Gray wrote:
The context
setting
should
override
the
widget.properties
setting,
that
is the
only reason why we
have a context
version of
the
setting.

Please respond
to this
one,
you
haven't responded to
the discussion
regarding
your
last commit
yet.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 8/07/2010,
at 9:49
PM,
hans...@apache.org
wrote:

Author:
hansbak
Date: Thu
Jul  8
09:49:57
2010
New
Revision:
961684

URL: http://svn.apache.org/viewvc?rev=961684&view=rev
Log:
make
widgetBoundaryCommentsEnabled work
as the
descriptions
states:
Widget
boundary
comments are enabled by
setting
widgetVerbose true
in
the context
Map, OR by setting

widget.verbose=true in
widget.properties.
And not let the
context override
the
widget.properties
setting

Modified:





ofbiz/trunk/framework/widget/src/org/ofbiz/widget/ModelWidget.java

Modified:




ofbiz/trunk/framework/widget/src/org/ofbiz/widget/ModelWidget.java
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/ModelWidget.java?rev=961684&r1=961683&r2=961684&view=diff





==============================================================================
---




ofbiz/trunk/framework/widget/src/org/ofbiz/widget/ModelWidget.java
(original)
+++




ofbiz/trunk/framework/widget/src/org/ofbiz/widget/ModelWidget.java
Thu Jul  8
09:49:57
2010
@@ -21,6
+21,7 @@
package
org.ofbiz.widget;
import
java.io.Serializable;
import
java.util.Map;
import
org.w3c.dom.Element;
+import
org.ofbiz.base.util.Debug;
import
org.ofbiz.base.util.UtilGenerics;
import

org.ofbiz.base.util.UtilProperties;

@@ -110,7
+111,7
@@
public class
ModelWidget
implements Seri

     */

    public
static
boolean


widgetBoundaryCommentsEnabled(Map<String, ?
extends
Object>
context) {



boolean
result =




"true".equals(UtilProperties.getPropertyValue("widget",

"widget.verbose"));
-

    if
(context != null)
{
+

    if
(result == false
&&  context
!=
null) {


    String str =
(String)


context.get(enableBoundaryCommentsParam);


    if (str !=
null) {


    result =
"true".equals(str);




--
Ofbiz on twitter:
http://twitter.com/apache_ofbiz
Myself on twitter:
http://twitter.com/hansbak

Antwebsystems.com:
Quality
services for
competitive rates.






--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com:
Quality
services
for
competitive rates.



--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality
services for
competitive rates.







--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for
competitive rates.
















Reply via email to