So, you're suggesting a grid widget would accept any screen widget
within a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and enhance UI
design. Furthermore, it will facilitate responsive design in Ofbiz. I
agree that form widget should apply to forms. I would recommend that we
create a table widget for multi-column lists instead of the proposed grid
widget. My thinking is that the grid widget should be used as a layout
widget on a level just beneath screens but higher than lower level widgets
(screenlets/forms/tables/menus/trees). In other words a screen contains
grids and grids contain lower level widgets. This pattern will enable us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7: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
