Hi Adrian, Would it not be a good thing to have all the linking definition to be refactored to one single definiton?
Currently we have: - link - hyperlink - sub-hyperlink It seems to me that they are intended to deliver the same functionality, but are applied differently per application area: 1. link -> menu, screen - but with different behaviour between the two, e.g. ajax-window doesn't work in a menu 2. hyperlink -> forms, commonly used to have a link associated to a field 3. sub-hyperlink -> forms, commonly used in a display entity associated to a field Best regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <kwikst...@gmail.com> wrote: > Yes. Cell/Column sizes in conjunction with screen media directives can > then be used to achieve responsive layouts. > > On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum < > adrian.c...@sandglass-software.com> wrote: > > > 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 > >>>>> > >>>>> > >>>>> > >>>> > >> >
