True. But would you not like it that this refactoring isn't a factor when a comparison between a release and trunk shows that trunk is performing worse than a release?
Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Sat, Jan 17, 2015 at 10:44 PM, Adrian Crum < adrian.c...@sandglass-software.com> wrote: > Comparisons can be done on any branch. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/17/2015 1:40 PM, Pierre Smits wrote: > >> Hi Adrian, >> >> I am inclined to say that any code improvement that removes quirkiness in >> current code or unpredictable behaviour while at the same time helping >> contributors to develop better solutions deserves a +1. >> >> However I have some concerns regarding the approach you're following. >> >> First, as we can expect that the quirkiness in current widget code is >> being >> utilized in various places in the dependent components, refactoring the >> widget code can lead to a multitude of issues regarding Screens and Forms >> in those components. I truly hope this will be as bad as I fear. >> >> Secondly, refactoring the widget code will have an impact on performance. >> I >> am sure we all hope (and some will expect it to be so) it is a positive >> effect, but we can't tell - at this moment in time - what it will be. >> >> Given the two concerns I would rather have seen that the refactoring was >> taking place in a separate development branch than in trunk. Having it >> done >> that way we would have the opportunity to compare the performance aspects >> of the refactored code against trunk (e.g. with Apache jMeter and such), >> and if favourable have another argument to tell to the users of old >> releases. >> >> Also while having the refactoring taking place in the development branch, >> we can not only isolate the aspects of my first concern (development >> branch >> issues vs trunk issues), but we will be able to better explain what the >> effects of the refactoring could be visavis (potential) issues of the >> users >> of old versions considering upgrading. >> >> Best regards, >> >> >> Pierre Smits >> >> *ORRTIZ.COM <http://www.orrtiz.com>* >> >> Services & Solutions for Cloud- >> Based Manufacturing, Professional >> Services and Retail & Trade >> http://www.orrtiz.com >> >> On Sat, Jan 17, 2015 at 6:46 PM, Adrian Crum < >> adrian.c...@sandglass-software.com> wrote: >> >> Some time ago I started working on the screen widget thread safety. There >>> were many places in code where widget models were being modified during >>> rendering - resulting in unpredictable behavior, and in some cases it >>> resulted in users having access to data they shouldn't be able to see. >>> >>> While doing that work, I was overwhelmed by the quantity of source code. >>> The screen widget library was built using a lot of copy-and-paste - >>> instead >>> of extracting and reusing common things. Scott started working on reusing >>> widget code, but that was just a small beginning. >>> >>> In a recent commit, I continued his work and made some more things >>> reusable. >>> >>> Next, I would like to reorganize the source code folder structure. Here >>> is >>> what I have pictured: >>> >>> org/ofbiz/widget >>> artifact (Artifact Info classes) >>> cache (Widget cache classes) >>> model (Widget models) >>> renderer (Widget renderers) >>> macro >>> html >>> xml >>> >>> I think the simplified folder structure makes more sense and it will make >>> it easier to locate classes. >>> >>> After that, I would like to add error checking code to the widget models >>> - >>> similar to what I did in Mini-Language. Right now, errors in widget XML >>> are >>> (sometimes) logged and widget parsing continues. If a developer does >>> something wrong, they will not know it unless they check the logs. I >>> would >>> like to change the behavior so widget XML errors throw an exception with >>> a >>> detailed error message that includes the XML file name and line number >>> where the error occurred. I believe this will benefit developers by >>> making >>> it clear when they have done something wrong. >>> >>> Finally, I would like to extract list functionality from the form widget >>> and create a new grid widget. So, instead of a form widget representing a >>> single data entry form OR a list, it will ONLY represent a single form. >>> If >>> you want a list, you use the grid widget. Initially, this change will be >>> backwards-compatible - the XML parser will accept a <form> element for >>> both >>> types and it will create the correct model based on the type attribute. >>> >>> Overall, my goal is to make screen widgets more developer-friendly, and >>> also to make it easier to innovate in the screen widget component. >>> >>> After all of this work is completed, I would like to backport it to the >>> R14 branch. >>> >>> Comments are welcome. >>> >>> >>> -- >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> >>
