Re: OFBiz UI work
Locked
12
12
 
|
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 David proposed doesn't offend me or discourage me. Instead, it motivates me to take a closer look at what my IDE and SVN client are doing to cause these unintentional formatting changes. I truly appreciate the time David took to address my problem. Without his detailed description of the problems with my patches, I wouldn't know what was wrong with them. David E. Jones wrote: > > 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 the > patch, then it will be rejected..." > > -David > > > On Jan 15, 2007, at 10:44 PM, Chris Howe wrote: > >> 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. >> >> >> --- "David E. Jones" <[hidden email]> wrote: >> >>> >>> 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 from >>> >>> JIRA >>> >>>> in a "sorry kid, you're wasting my time" dismissal >>>> (email impressions added for levity). Anything >>> >>> less >>> >>>> is what is currently going on and wouldn't need a >>>> vote. People aren't tempted to vote on the status >>>> quo. >>>> >>>> --- "David E. Jones" <[hidden email]> >>> >>> wrote: >>> >>>> >>>>> >>>>> 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 >>>>> >>>>>> 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 with >>>>>> rejection policies, you will then have less of >>> >>> it >>> >>>>> to >>>>> >>>>>> review and thereby less solutions making it back >>>>> >>>>> into >>>>> >>>>>> the project. >>>>>> >>>>>> --- "David E. Jones" <[hidden email]> >>>>> >>>>> wrote: >>>>> >>>>>> >>>>>>> >>>>>>> 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 ASAP, but if your patch breaks >>>>>>> existing code (for >>>>>>> example), then that needs to be fixed before >>> >>> the >>> >>>>>>> commit is done >>>>>>> (either by the committer, the contributor, or >>> >>> an >>> >>>>>>> interested third >>>>>>> party). >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> It's great that people want to contribute, but >>> >>> in >>> >>>>> or >>>>> >>>>>>> to contribute to >>>>>>> something as large and complex as OFBiz a large >>>>>>> amount of effort is >>>>>>> necessary, and anyone that wants to help out >>> >>> will >>> >>>>>>> err on the side of >>>>>>> extra effort, caution and review, and >>>>> >>>>> consideration >>>>> >>>>>>> of more general >>>>>>> requirements and designs rather just one's own >>>>>>> requirements. >>>>>>> >>>>>>> -David >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jan 15, 2007, at 7:42 PM, Jonathon -- >>> >>> Improov >>> >>>>>>> wrote: >>>>>>> >>>>>>>> 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 >>>>>>> >>>>>>> automatically filter out >>>>>>> >>>>>>>> formatting changes in my audit, and then >>> >>> INCLUDE >>> >>>>>>> the formatting >>>>>>> >>>>>>>> changes. After all, there's no harm removing >>>>> >>>>> some >>>>> >>>>>>> extra spaces at >>>>>>> >>>>>>>> the end of lines, part of clean up. >>>>>>>> >>>>>>>> We often try to make things easier for the >>>>> >>>>> person >>>>> >>>>>>> who is doing a >>>>>>> >>>>>>>> task that we have no control over. Eg, I'd >>> >>> keep >>> >>>>> my >>>>> >>>>>>> mouth really >>>>>>> >>>>>>>> wide open for my dentist just so his vision is >>>>>>> >>>>>>> 20/20, no arguments >>>>>>> >>>>>>>> from me; I could afford to be slack about this >>>>>>> >>>>>>> "mouth wide-open >>>>>>> >>>>>>>> policy" if I were able to do the dentistry >>>>> >>>>> myself. >>>>> >>>>>>>> >>>>>>>> But you're certainly right that it'll exclude >>>>> >>>>> some >>>>> >>>>>>> people, >>>>>>> >>>>>>>> especially folks who use editors that do not >>>>> >>>>> give >>>>> >>>>>>> very much control >>>>>>> >>>>>>>> to users. >>>>>>>> >>>>>>>> Jonathon >>>>>>>> >>>>>>>> Chris Howe wrote: >>>>>>>> >>>>>>>>> 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, >>>>>>> >>>>>>> there's >>>>>>> >>>>>>>>> another :-) ). >>>>>>>>> --- Jonathon -- Improov <[hidden email]> >>>>> >>>>> wrote: >>>>> >>>>>>>>>> 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 also easy to go through every >>>>> >>>>> set >>>>> >>>>>>> of >>>>>>> >>>>>>>>>> changes, do an interactive-search for 1st >>> >>> >> === message truncated === >> > |
|
|
In reply to this post by David E Jones
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 helps people to understand the type of mindset required for success! - Andrew On Tue, 2007-01-16 at 07:56 -0800, Adrian Crum wrote: > 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 David proposed doesn't offend me > or discourage me. Instead, it motivates me to take a closer look at what my IDE > and SVN client are doing to cause these unintentional formatting changes. > > I truly appreciate the time David took to address my problem. Without his > detailed description of the problems with my patches, I wouldn't know what was > wrong with them. > > > David E. Jones wrote: > > > > 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 the > > patch, then it will be rejected..." > > > > -David > > > > > > On Jan 15, 2007, at 10:44 PM, Chris Howe wrote: > > > >> 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. > >> > >> > >> --- "David E. Jones" <[hidden email]> wrote: > >> > >>> > >>> 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 from > >>> > >>> JIRA > >>> > >>>> in a "sorry kid, you're wasting my time" dismissal > >>>> (email impressions added for levity). Anything > >>> > >>> less > >>> > >>>> is what is currently going on and wouldn't need a > >>>> vote. People aren't tempted to vote on the status > >>>> quo. > >>>> > >>>> --- "David E. Jones" <[hidden email]> > >>> > >>> wrote: > >>> > >>>> > >>>>> > >>>>> 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 > >>>>> > >>>>>> 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 with > >>>>>> rejection policies, you will then have less of > >>> > >>> it > >>> > >>>>> to > >>>>> > >>>>>> review and thereby less solutions making it back > >>>>> > >>>>> into > >>>>> > >>>>>> the project. > >>>>>> > >>>>>> --- "David E. Jones" <[hidden email]> > >>>>> > >>>>> wrote: > >>>>> > >>>>>> > >>>>>>> > >>>>>>> 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 ASAP, but if your patch breaks > >>>>>>> existing code (for > >>>>>>> example), then that needs to be fixed before > >>> > >>> the > >>> > >>>>>>> commit is done > >>>>>>> (either by the committer, the contributor, or > >>> > >>> an > >>> > >>>>>>> interested third > >>>>>>> party). > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> It's great that people want to contribute, but > >>> > >>> in > >>> > >>>>> or > >>>>> > >>>>>>> to contribute to > >>>>>>> something as large and complex as OFBiz a large > >>>>>>> amount of effort is > >>>>>>> necessary, and anyone that wants to help out > >>> > >>> will > >>> > >>>>>>> err on the side of > >>>>>>> extra effort, caution and review, and > >>>>> > >>>>> consideration > >>>>> > >>>>>>> of more general > >>>>>>> requirements and designs rather just one's own > >>>>>>> requirements. > >>>>>>> > >>>>>>> -David > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Jan 15, 2007, at 7:42 PM, Jonathon -- > >>> > >>> Improov > >>> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> 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 > >>>>>>> > >>>>>>> automatically filter out > >>>>>>> > >>>>>>>> formatting changes in my audit, and then > >>> > >>> INCLUDE > >>> > >>>>>>> the formatting > >>>>>>> > >>>>>>>> changes. After all, there's no harm removing > >>>>> > >>>>> some > >>>>> > >>>>>>> extra spaces at > >>>>>>> > >>>>>>>> the end of lines, part of clean up. > >>>>>>>> > >>>>>>>> We often try to make things easier for the > >>>>> > >>>>> person > >>>>> > >>>>>>> who is doing a > >>>>>>> > >>>>>>>> task that we have no control over. Eg, I'd > >>> > >>> keep > >>> > >>>>> my > >>>>> > >>>>>>> mouth really > >>>>>>> > >>>>>>>> wide open for my dentist just so his vision is > >>>>>>> > >>>>>>> 20/20, no arguments > >>>>>>> > >>>>>>>> from me; I could afford to be slack about this > >>>>>>> > >>>>>>> "mouth wide-open > >>>>>>> > >>>>>>>> policy" if I were able to do the dentistry > >>>>> > >>>>> myself. > >>>>> > >>>>>>>> > >>>>>>>> But you're certainly right that it'll exclude > >>>>> > >>>>> some > >>>>> > >>>>>>> people, > >>>>>>> > >>>>>>>> especially folks who use editors that do not > >>>>> > >>>>> give > >>>>> > >>>>>>> very much control > >>>>>>> > >>>>>>>> to users. > >>>>>>>> > >>>>>>>> Jonathon > >>>>>>>> > >>>>>>>> Chris Howe wrote: > >>>>>>>> > >>>>>>>>> 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, > >>>>>>> > >>>>>>> there's > >>>>>>> > >>>>>>>>> another :-) ). > >>>>>>>>> --- Jonathon -- Improov <[hidden email]> > >>>>> > >>>>> wrote: > >>>>> > >>>>>>>>>> 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 also easy to go through every > >>>>> > >>>>> set > >>>>> > >>>>>>> of > >>>>>>> > >>>>>>>>>> changes, do an interactive-search for 1st > >>> > >>> > >> === message truncated === > >> > > Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com |
|
|
In reply to this post by Guido Amarilla
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 OFBiz (which has already been thoroughly reviewed and taken care of, as of a few months ago). -David |
smime.p7s (3K) |
|
OK
2007/1/16, David E. Jones <[hidden email]>: > > 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 OFBiz (which has already been thoroughly reviewed and > taken care of, as of a few months ago). > > -David > > > > -- Guido Amarilla |
Re: OFBiz UI work, Plus New Revelations
|
|
In reply to this post by Adrian Crum
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 my editor would do such a thing without my permission. Then I got to thinking that it makes a lot of sense. Less unnecessary white space equals less fluff the compiler has to trudge through and less fluff in HTML code. Hey! Wait a second... many of those files that were unintentionally formatted were FTL files. Does that mean that OFBiz servers are spewing out unnecessary fluff? I viewed the page source on a typical OFBiz web page and sure enough - OFBiz's markup has unnecessary white space at the end of the lines. Going through all of the FTL files and cleaning them up would be easy to do with a script or something, but the reduction in HTML output would be small. Where I see a huge amount of unnecessary markup is with indentation. Our four character indentation rule results in things like a simple </div> tag being preceded by twelve to sixteen space characters. Our servers are working very hard to output nicely indented markup. |
|
|
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 contributors stating that all tabs should be converted to spaces. That's quite the norm in many, if not all, projects. You mean you found tabs in FTL sources? In any case, all these don't affect me. Use Emacs! I don't remove or change any whitespaces, not even change tabs to spaces. Far as I'm concerned, I will continue to submit patches that have "intended changes only". I'm kinda obsessive compulsively clean and organized. I'd rather have say the original authors clean up the extra whitespaces, and check in with log saying "cleaned up whitespaces". My check in log will only be "fixed this bug", not "fixed this bug, plus cleaned up whitespaces". But yeah, your editor isn't wrong to clean up those whitespaces. No wait. It's wrong. Or at least it's wrong not to allow you to configure that behavior. Jonathon Adrian Crum wrote: > 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 my editor would do such a thing without my > permission. Then I got to thinking that it makes a lot of sense. Less > unnecessary white space equals less fluff the compiler has to trudge > through and less fluff in HTML code. > > Hey! Wait a second... many of those files that were unintentionally > formatted were FTL files. Does that mean that OFBiz servers are spewing > out unnecessary fluff? I viewed the page source on a typical OFBiz web > page and sure enough - OFBiz's markup has unnecessary white space at the > end of the lines. > > Going through all of the FTL files and cleaning them up would be easy to > do with a script or something, but the reduction in HTML output would > be small. Where I see a huge amount of unnecessary markup is with > indentation. Our four character indentation rule results in things like > a simple </div> tag being preceded by twelve to sixteen space > characters. Our servers are working very hard to output nicely indented > markup. > > |
Re: OFBiz UI work, Plus New Revelations
|
|
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 any unnecessary white space in FTL files translates into unnecessary white space being served to web clients. I was merely sharing an observation. I'm not suggesting that we change the best practices. |
Re: OFBiz UI work, Plus New Revelations
|
|
In reply to this post by Adrian Crum
Just for grins, I inserted <#compress> </#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's appearance changed a little. Adrian Crum wrote: > 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 my editor would do such a thing without my > permission. Then I got to thinking that it makes a lot of sense. Less > unnecessary white space equals less fluff the compiler has to trudge > through and less fluff in HTML code. > > Hey! Wait a second... many of those files that were unintentionally > formatted were FTL files. Does that mean that OFBiz servers are spewing > out unnecessary fluff? I viewed the page source on a typical OFBiz web > page and sure enough - OFBiz's markup has unnecessary white space at the > end of the lines. > > Going through all of the FTL files and cleaning them up would be easy to > do with a script or something, but the reduction in HTML output would > be small. Where I see a huge amount of unnecessary markup is with > indentation. Our four character indentation rule results in things like > a simple </div> tag being preceded by twelve to sixteen space > characters. Our servers are working very hard to output nicely indented > markup. > > |
Re: OFBiz UI work, Plus New Revelations
|
|
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 server (httpd). -David On Jan 18, 2007, at 1:40 PM, Adrian Crum wrote: > Just for grins, I inserted <#compress> </#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's appearance changed a little. > > > Adrian Crum wrote: > >> 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 my editor would do such a thing without >> my permission. Then I got to thinking that it makes a lot of >> sense. Less unnecessary white space equals less fluff the compiler >> has to trudge through and less fluff in HTML code. >> Hey! Wait a second... many of those files that were >> unintentionally formatted were FTL files. Does that mean that >> OFBiz servers are spewing out unnecessary fluff? I viewed the page >> source on a typical OFBiz web page and sure enough - OFBiz's >> markup has unnecessary white space at the end of the lines. >> Going through all of the FTL files and cleaning them up would be >> easy to do with a script or something, but the reduction in HTML >> output would be small. Where I see a huge amount of unnecessary >> markup is with indentation. Our four character indentation rule >> results in things like a simple </div> tag being preceded by >> twelve to sixteen space characters. Our servers are working very >> hard to output nicely indented markup. |
Re: OFBiz UI work, Plus New Revelations
|
|
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 where Freemarker/Tomcat/whatever is set up to compress ALL markup, then see how much more responsive the web site is. David E. Jones wrote: > > 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 server (httpd). > > -David > > > On Jan 18, 2007, at 1:40 PM, Adrian Crum wrote: > >> Just for grins, I inserted <#compress> </#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's appearance changed a little. >> >> >> Adrian Crum wrote: >> >>> 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 my editor would do such a thing without my >>> permission. Then I got to thinking that it makes a lot of sense. >>> Less unnecessary white space equals less fluff the compiler has to >>> trudge through and less fluff in HTML code. >>> Hey! Wait a second... many of those files that were unintentionally >>> formatted were FTL files. Does that mean that OFBiz servers are >>> spewing out unnecessary fluff? I viewed the page source on a typical >>> OFBiz web page and sure enough - OFBiz's markup has unnecessary >>> white space at the end of the lines. >>> Going through all of the FTL files and cleaning them up would be >>> easy to do with a script or something, but the reduction in HTML >>> output would be small. Where I see a huge amount of unnecessary >>> markup is with indentation. Our four character indentation rule >>> results in things like a simple </div> tag being preceded by twelve >>> to sixteen space characters. Our servers are working very hard to >>> output nicely indented markup. > > |
Re: OFBiz UI work, Plus New Revelations
|
|
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 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 where > Freemarker/Tomcat/whatever is set up to compress ALL markup, then see > how much more responsive the web site is. > > > David E. Jones wrote: > >> >> 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 server (httpd). >> >> -David >> >> >> On Jan 18, 2007, at 1:40 PM, Adrian Crum wrote: >> >>> Just for grins, I inserted <#compress> </#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's appearance changed a little. >>> >>> >>> Adrian Crum wrote: >>> >>>> 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 my editor would do such a thing without >>>> my permission. Then I got to thinking that it makes a lot of sense. >>>> Less unnecessary white space equals less fluff the compiler has to >>>> trudge through and less fluff in HTML code. >>>> Hey! Wait a second... many of those files that were unintentionally >>>> formatted were FTL files. Does that mean that OFBiz servers are >>>> spewing out unnecessary fluff? I viewed the page source on a >>>> typical OFBiz web page and sure enough - OFBiz's markup has >>>> unnecessary white space at the end of the lines. >>>> Going through all of the FTL files and cleaning them up would be >>>> easy to do with a script or something, but the reduction in HTML >>>> output would be small. Where I see a huge amount of unnecessary >>>> markup is with indentation. Our four character indentation rule >>>> results in things like a simple </div> tag being preceded by twelve >>>> to sixteen space characters. Our servers are working very hard to >>>> output nicely indented markup. >> >> >> > |
|
|
In reply to this post by Adrian Crum
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 be crazy and code tons of unnecessary whitespaces into an FTL. > It would be interesting to try out an OFBiz installation where > Freemarker/Tomcat/whatever is set up to compress ALL markup, then see > how much more responsive the web site is. Not by much if server-side processing is hefty. Savings from reduced time of transfer (of web content) is amortized in that case. But in general, if you can, use compression. Or actually, for maximum compatibility with all browsers, maybe we shouldn't (we never know). Jonathon 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 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 where > Freemarker/Tomcat/whatever is set up to compress ALL markup, then see > how much more responsive the web site is. > > > David E. Jones wrote: >> >> 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 server (httpd). >> >> -David >> >> >> On Jan 18, 2007, at 1:40 PM, Adrian Crum wrote: >> >>> Just for grins, I inserted <#compress> </#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's appearance changed a little. >>> >>> >>> Adrian Crum wrote: >>> >>>> 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 my editor would do such a thing without >>>> my permission. Then I got to thinking that it makes a lot of sense. >>>> Less unnecessary white space equals less fluff the compiler has to >>>> trudge through and less fluff in HTML code. >>>> Hey! Wait a second... many of those files that were unintentionally >>>> formatted were FTL files. Does that mean that OFBiz servers are >>>> spewing out unnecessary fluff? I viewed the page source on a >>>> typical OFBiz web page and sure enough - OFBiz's markup has >>>> unnecessary white space at the end of the lines. >>>> Going through all of the FTL files and cleaning them up would be >>>> easy to do with a script or something, but the reduction in HTML >>>> output would be small. Where I see a huge amount of unnecessary >>>> markup is with indentation. Our four character indentation rule >>>> results in things like a simple </div> tag being preceded by twelve >>>> to sixteen space characters. Our servers are working very hard to >>>> output nicely indented markup. >> >> > > |
Re: OFBiz UI work, Plus New Revelations
|
|
In reply to this post by David E Jones
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 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 server (httpd). > > -David > > > On Jan 18, 2007, at 1:40 PM, Adrian Crum wrote: > >> Just for grins, I inserted <#compress> </#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's appearance changed a little. >> >> >> Adrian Crum wrote: >> >>> 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 my editor would do such a thing without my >>> permission. Then I got to thinking that it makes a lot of sense. >>> Less unnecessary white space equals less fluff the compiler has to >>> trudge through and less fluff in HTML code. >>> Hey! Wait a second... many of those files that were unintentionally >>> formatted were FTL files. Does that mean that OFBiz servers are >>> spewing out unnecessary fluff? I viewed the page source on a typical >>> OFBiz web page and sure enough - OFBiz's markup has unnecessary >>> white space at the end of the lines. >>> Going through all of the FTL files and cleaning them up would be >>> easy to do with a script or something, but the reduction in HTML >>> output would be small. Where I see a huge amount of unnecessary >>> markup is with indentation. Our four character indentation rule >>> results in things like a simple </div> tag being preceded by twelve >>> to sixteen space characters. Our servers are working very hard to >>> output nicely indented markup. > > |
Re: OFBiz UI work, Plus New Revelations
|
|
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-connector (already set in the default config): <property name="compressableMimeType" value="text/html,text/xml,text/ plain"/> <property name="compression" value="on"/> -Joe |
Re: OFBiz UI work, Plus New Revelations
|
|
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 OFBiz uses. > > > > It's under http-connector (already set in the default config): > > <property name="compressableMimeType" value="text/html,text/xml,text/ > plain"/> > <property name="compression" value="on"/> > > -Joe |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |