With columns already existing, rendering them inside rows would constitute a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum < [email protected]> 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 < >> [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 >>> >>> >>
