Thanks! 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 11:17 PM, Adrian Crum < adrian.c...@sandglass-software.com> wrote: > Done. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/23/2015 12:45 PM, Pierre Smits wrote: > >> 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 <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 5:01 PM, Pierre Smits <pierre.sm...@gmail.com> >> wrote: >> >> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >>
