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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
