Thanks Joe!
Joe Eckard wrote:
On Jan 19, 2007, at 4:43 PM, Adrian Crum wrote:
I found on the Tomcat website a configuration setting for compressing
outgoing html/xml (http://tomcat.apache.org/tomcat-5.5-
doc/config/http.html) but I don't where to configure it in the
embedded version that
On Jan 19, 2007, at 4:43 PM, Adrian Crum wrote:
I found on the Tomcat website a configuration setting for
compressing outgoing html/xml (http://tomcat.apache.org/tomcat-5.5-
doc/config/http.html) but I don't where to configure it in the
embedded version that OFBiz uses.
It's under http-c
I found on the Tomcat website a configuration setting for compressing outgoing
html/xml (http://tomcat.apache.org/tomcat-5.5-doc/config/http.html) but I don't
where to configure it in the embedded version that OFBiz uses.
David E. Jones wrote:
The best way I've seen to handle this sort of t
Adrian,
> The zipped pages browser setting doesn't address the fundamental issue I
> presented: OFBiz servers are pushing out a lot of unnecessary markup.
I'd guess there won't be too much unnecessary "whitespaces" (is this what you mean by unnecessary
markup?). But I don't know. Someone could
Oh wait. I misread what you said. You're suggesting zipped pages sent out from
the server that the browser can unzip. Gotcha. Great idea. Thanks.
Adrian Crum wrote:
As I mentioned in another email, I was just making an observation. It's
food for thought.
The zipped pages browser setting doe
As I mentioned in another email, I was just making an observation. It's food for
thought.
The zipped pages browser setting doesn't address the fundamental issue I
presented: OFBiz servers are pushing out a lot of unnecessary markup.
It would be interesting to try out an OFBiz installation whe
The best way I've seen to handle this sort of thing is to take
advantage of the fact that pretty much all browsers support zipped
pages. I haven't set this sort of thing up in a LONG time, but there
are probably ways to do it with Tomcat, and definitely ways to do it
with the Apache web s
Just for grins, I inserted <#compress> FTL directives in the Party
Manager FTL files to see how much smaller the markup would be. Results:
Before compress - 45k
After compress - 35k
33% less markup.
The drawback is, some of the layout seems to depend on some of the FTL
whitespace, so the page
Jonathon -- Improov wrote:
Adrian,
I don't understand what you mean by "OFBiz servers are spewing out
unnecessary stuff". Those FTLs with unnecessary whitespaces are probably
coded that way (by mistake or otherwise), not generated and spewed by
some servers.
The point I was making is that a
Adrian,
I don't understand what you mean by "OFBiz servers are spewing out unnecessary stuff". Those FTLs
with unnecessary whitespaces are probably coded that way (by mistake or otherwise), not generated
and spewed by some servers.
As for indentation, I recall the "best practices" page for co
After spending some time examining the unintentional formatting changes in my
patch files, I discovered that my editor automatically strips off unnecessary
white space at the end of every line. I can't find a way to shut it off, so I'll
have to switch to another IDE.
At first I was upset that
OK
2007/1/16, David E. Jones <[EMAIL PROTECTED]>:
On Jan 16, 2007, at 5:11 AM, Guido Amarilla wrote:
> BTW, I did my homework and faxed a signed iCLA to The Apache
> Foundation.
Not that it's a problem in any way, but why was it that you sent in
an iCLA?
Unless you are becoming a committer a
On Jan 16, 2007, at 5:11 AM, Guido Amarilla wrote:
BTW, I did my homework and faxed a signed iCLA to The Apache
Foundation.
Not that it's a problem in any way, but why was it that you sent in
an iCLA?
Unless you are becoming a committer at the ASF or had contributed pre-
ASF code to OFB
Adrian,
Too true, I suspect if David was paid standard rate for all the time
he's spent explaining what's wrong with patches he'd probably have
retired by now!
Being thick skinned is all part of working with a disparate group of
people on a very generic project. So perhaps a rejection policy also
Wow. This subject sure took off from my original dilemma.
Actually, there's an element of truth to what Chris said. At first glance the
policy seems mean-spirited. But as was mentioned in another reply, it's a good
way to train the submitters.
Personally, I have a pretty thick skin, so what D
ginal Message -
> > From: "Guido Amarilla" <[EMAIL PROTECTED]>
> > To:
> > Sent: Tuesday, January 16, 2007 5:58 AM
> > Subject: Re: OFBiz UI work
> >
> >
> > > I´m giving my opinion, because it seems obvious to me that if you
> &
From: "Jonathon -- Improov" <[EMAIL PROTECTED]>
> Chris has a point. There's definitely an implicit "rejection policy" already
> in place.
[...snip...]
> I've submitted about 3-4 patches, 3 (75-90%) of those early patches have
> wrong "path to file" (I
> created patch from same folder as patch
6, 2007 5:58 AM
Subject: Re: OFBiz UI work
> I´m giving my opinion, because it seems obvious to me that if you
> reject a patch, the contributor will correct it in the 99% of the
> times...and will learn, so the next time he probably won´t commit the
> same mistakes.
> This way
uary 16, 2007 5:58 AM
Subject: Re: OFBiz UI work
> I´m giving my opinion, because it seems obvious to me that if you
> reject a patch, the contributor will correct it in the 99% of the
> times...and will learn, so the next time he probably won´t commit the
> same mistakes.
> This
So, yeah, that slows things down and is inconvenient, but keep in
mind that a large portion of patches that come into OFBiz break
existing functionality. This seems to happen around once a week or
so, at least.
Automated testing should help with this.
If I may make a suggestion, it would be tha
So, then how does the parodied scenario demonstrate an
imagination if that's exactly what you're wanting to
do?
--- "David E. Jones" <[EMAIL PROTECTED]> wrote:
>
> I'm not sure what to say, perhaps what I originally
> said would be
> helpful:
>
> "People tend to slip things into patches
> ac
I'm not sure what to say, perhaps what I originally said would be
helpful:
"People tend to slip things into patches accidentally all the time.
I'm tempted to begun the voting process for a new policy that says
that if there is anything in the patch file not described in the
summary of t
Chris has a point. There's definitely an implicit "rejection policy" already in
place.
Given a strong rejection policy, there are 2 opposite spectrums to its implementation. You can
follow the Singapore method that says "Our fatherland says this, so this is it. You cannot make a
U-turn because
Sorry, I don't know why that quote didn't hit me right
the first time. My apologies to W.C. Fields. Go
away, kid, you bother me. I really butchered it. I
mean _really :-)
So, if that's not the policy and procedure you're
looking to adopt, please elaborate on what you're
tempted to propose.
--
You have quite an imagination.
-David
On Jan 15, 2007, at 10:01 PM, Chris Howe wrote:
Being tempted to ask for a vote, insinuates that you
want to condone a practice whereby if you go to review
a patch like in Adrian's case and it has superflous
formatting changes, that you would delete it f
Being tempted to ask for a vote, insinuates that you
want to condone a practice whereby if you go to review
a patch like in Adrian's case and it has superflous
formatting changes, that you would delete it from JIRA
in a "sorry kid, you're wasting my time" dismissal
(email impressions added for levi
I´m giving my opinion, because it seems obvious to me that if you
reject a patch, the contributor will correct it in the 99% of the
times...and will learn, so the next time he probably won´t commit the
same mistakes.
This way we reduce the effort to the few commiters increasing the
chances for the
Ummm... what do you think when you think of a rejection policy? We
already have patch rejection policies when problems are found...
-David
On Jan 15, 2007, at 9:44 PM, Chris Howe wrote:
I agree. I think it's better that we strongly
encourage certain practices (as we are doing now) and
br
I agree. I think it's better that we strongly
encourage certain practices (as we are doing now) and
bring people to notice when those practices could be
improved, but rejection policies put your _means
perspective ahead of your _ends. Contributions may be
easier to review, but I can gaurantee you
Yes, we want more people, but I don't think anyone wants
indiscriminate changes going into SVN! I hate surprises when I check
out as much as the next guy, probably more than the next guy in many
cases.
Thinking about the next guy is the real key here. You may want to get
your patches in
Heh. True. I definitely want MORE people involved in OFBiz.
But since I'm not a committer, I'd rather make things easier for the committers. I have no control
over how easy or difficult it is to handle patches with "extra unintended footprints".
If I were a committer, I would try to automatica
I don't know that rejection policies are very
community friendly. Treating SVN code changes like
the keeper of the Bridge of Death (Monty Python
Reference, smile) may find less people willing to do
in this do-ocracy. Many of us rather like what's left
of our anarco-sydicalist commune (oh look, th
David,
I agree with the rejection policy.
One suggestion on procedure to take when self-reviewing a patch before submitting it. Look at the
diff to see if there are changes we cannot account for. Using KDiff also makes things easier, even
when dealing with formatting changes.
In Emacs, it's
Looking at his patch, I don't believe Adrian made the
formatting changes. His editor did. It's clearing
whitespace at the end of lines in places you wouldn't
even expect him to be touching (the license header).
Adrian, what IDE and xml editor are you using?
There's probably a setting somewhere
Moving this back to the mailing list...
On Jan 15, 2007, at 5:34 PM, Adrian Crum wrote:
David E. Jones wrote:
When reviewing a patch lines with formatting changes only are
EXTREMELY time consuming, and the patch attached that issue is a
good example of a painful one. For each of those l
35 matches
Mail list logo
