Hi Adrian, this work is welcome !
The widget model is an important element to deploy OFBiz as an ERP and
its own goal is to be improved to be more user-friendly and easy to
maintain for developer.
I see two axis that are missing at this time :
* create high configurable portal page to offer the ability to orientate
a screen on a business cover (business permission, portlet structure, ...)
* Add a binary renderer to get the ability to create Xls flow from
widget screens (xls or other) because at this time we can only use a
string buffer
With your overhaul proposition and the boostrap branch, we can have a
screen killer framework ;)
How can I help you actually ?
Le 17/01/2015 18:46, Adrian Crum a écrit :
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.
