Take a look at the visitor design pattern I added and see if that will
accommodate your binary renderer. There is an example implementation in
XmlWidgetVisitor.java.
The portlets are outside the scope of my current effort.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/30/2015 12:31 PM, Nicolas Malin wrote:
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.
