Return-Path: X-Original-To: apmail-ofbiz-dev-archive@www.apache.org Delivered-To: apmail-ofbiz-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C456B10D70 for ; Fri, 23 Jan 2015 21:21:37 +0000 (UTC) Received: (qmail 90200 invoked by uid 500); 23 Jan 2015 21:19:02 -0000 Delivered-To: apmail-ofbiz-dev-archive@ofbiz.apache.org Received: (qmail 90168 invoked by uid 500); 23 Jan 2015 21:19:02 -0000 Mailing-List: contact dev-help@ofbiz.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ofbiz.apache.org Delivered-To: mailing list dev@ofbiz.apache.org Received: (qmail 73477 invoked by uid 99); 23 Jan 2015 20:47:03 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Jan 2015 20:47:03 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of pierre.smits@gmail.com designates 209.85.217.169 as permitted sender) Received: from [209.85.217.169] (HELO mail-lb0-f169.google.com) (209.85.217.169) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Jan 2015 20:45:43 +0000 Received: by mail-lb0-f169.google.com with SMTP id f15so9063499lbj.0 for ; Fri, 23 Jan 2015 12:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5JSCCLG6/mrQ/a/ezJiJ0noOSqcf0uBoeDfuWdH49So=; b=Fkie6+EjOaPUaRAzzb1VCJlrBG8QQ/c+SNbWx0QyUF1FCsV162Vn8dwuxTMUbGKdTn Klj7w56GGzQbmHoUNbt8pAQk+Xe0XD4NQafShBhxgoYR6i7KgENK1EtvpQcH5dkwkJpC sug2xMdQj1El269vZNiZm/ZsnxGetdt3+BMB1L4Leh/59ikhA0ZDxmhjMQJD6CqTPmlX 7V+G5H4cm2DBzL/T7UgUuVgRfJKgTFwiLXd+6ROCZgQ7VMWpm+7Zlb6c3tyGELoWt7Lz S6QwAjFkO47YsRyUYAQFOtqRmWF7AbQlD7o/rc15dbw3gkl3PyHSsWi/BnftYn9njDid 9lYQ== MIME-Version: 1.0 X-Received: by 10.112.160.33 with SMTP id xh1mr9502181lbb.60.1422045941766; Fri, 23 Jan 2015 12:45:41 -0800 (PST) Received: by 10.25.21.227 with HTTP; Fri, 23 Jan 2015 12:45:41 -0800 (PST) In-Reply-To: References: <54BAA00B.6080600@sandglass-software.com> <54BBDD25.7050405@sandglass-software.com> <54BC9290.9070403@sandglass-software.com> <54C25B2A.90006@sandglass-software.com> <54C26633.3070705@sandglass-software.com> Date: Fri, 23 Jan 2015 21:45:41 +0100 Message-ID: Subject: Re: Widget Overhaul From: Pierre Smits To: "dev@ofbiz.apache.org" Content-Type: multipart/alternative; boundary=001a11c33eac369f71050d57df8f X-Virus-Checked: Checked by ClamAV on apache.org --001a11c33eac369f71050d57df8f Content-Type: text/plain; charset=UTF-8 Adrian, Could you update http://ofbiz.apache.org/dtds/ so that the underlaying xsd files reflect the recent changes? Best regards, Pierre Smits *ORRTIZ.COM * Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Fri, Jan 23, 2015 at 5:01 PM, Pierre Smits wrote: > I have created the placeholder for now: > https://issues.apache.org/jira/browse/OFBIZ-6034 > > Pierre Smits > > *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 > wrote: > >> Ahh. Ok. >> >> Thanks for the insights. >> >> Best regards, >> >> Pierre Smits >> >> *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.crum@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: >>>> >>>> >>> "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: >>>> >>>> >>>> >>> "${uiLabelMap.CommonCreateNew}" width="1000" height="600"> >>>> >>>> >>>> >>>> >>>> >>>> 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 * >>>> 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.crum@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 * >>>>>> >>>>>> 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 >>>>>> 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.crum@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.crum@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.crum@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
>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >> > --001a11c33eac369f71050d57df8f--