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 >
