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 < [email protected]> 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 < >> [email protected]> 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 <[email protected]> >>>> 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 < >>>>> [email protected]> 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 < >>>>>>> [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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>
