I am not doing anything that affects performance, so I am not interested
in a comparison.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 2:58 PM, Pierre Smits wrote:
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
