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

Reply via email to