I have created the placeholder for now: https://issues.apache.org/jira/browse/OFBIZ-6034
Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Fri, Jan 23, 2015 at 4:24 PM, Pierre Smits <pierre.sm...@gmail.com> wrote: > Ahh. Ok. > > Thanks for the insights. > > 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 Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum < > adrian.c...@sandglass-software.com> wrote: > >> Right. The renderers need to be updated to render links consistently. So >> far, I have avoided touching the renderers. I will work on those later if I >> have time. Meanwhile, feel free to create a patch and I will apply it. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 1/23/2015 7:01 AM, Pierre Smits wrote: >> >>> Yes, I thought so too. >>> >>> But when I use link in a Sreen.xml, like example below: >>> >>> <link link-type="ajax-window" target= >>> "newaction?partyId=${parameters.partyId}" width="1000" height="400" >>> text= >>> "${uiLabelMap.CommonCreateNew}" style="buttontext create"/> >>> I get a popup window. >>> >>> Whereas when I use the same in a menu-item, like: >>> >>> <menu-item name="newaction" title="${uiLabelMap. >>> SEPASetBankAttributes}"> >>> <link link-type="ajax-window" target="nAttributeLayer" title= >>> "${uiLabelMap.CommonCreateNew}" width="1000" height="600"> >>> <parameter param-name="partyId" from-field="partyId"/> >>> </link> >>> </menu-item> >>> >>> >>> it doesn't open the screen in a popup wind, in stead it renders the new >>> screen in the browser window. >>> >>> 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 Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum < >>> adrian.c...@sandglass-software.com> wrote: >>> >>> I did that already - in the schema and in code. There is a common link >>>> type, then the various widgets extend it to add their specific >>>> attributes. >>>> >>>> Adrian Crum >>>> Sandglass Software >>>> www.sandglass-software.com >>>> >>>> On 1/23/2015 1:45 AM, Pierre Smits wrote: >>>> >>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >
