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 < [email protected]> 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
