So I can use ajax-window in a screen, but then must I resort to a complex setup in a section with regards to conditon settings to get an ajax window.
Or when using a menu and menu item to utilise conditions, I must resort to calling a javascript to get an ajax window. 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:01 PM, Pierre Smits <pierre.sm...@gmail.com> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >
