You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@sandglass-software.com> on 2015/01/17 18:46:51 UTC
Widget Overhaul
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
Re: Widget Overhaul
Posted by Christian Carlow <ch...@gmail.com>.
Thanks again for the feedback Adrian,
I updated OFBIZ-6404 patch so that form/grid embedded menu rendering is
treated as display instead of edit fields. This causes the menus to be
rendered outside the edit form that gets created preventing violation of
html standard conformance.
Extra logic was also added to handle menus of type hidden form so that
the row itemIndex is appended to the end of the id, otherwise duplicate
ids get rendered preventing the link javascript submissions from
triggering. This seemed like a hack possibly handled better another
way.
OFBIZ-6501 and OFBIZ-6502 have been created to support embedding of
screens and forms/grids within grids based on OFBIZ-6404 menu embedding.
The same rowItem index id appending logic will probably need to be
included with patches for those issues but the implementation will
likely be more complex since grids may contain grids may contain grids
and each row itemIndex will have to be appended until the last row is
reached.
On Sun, 2015-06-14 at 10:12 -0700, Adrian Crum wrote:
> Keep in mind that menu items are rendered as forms for a reason - to
> fight XSS attacks. So, whatever solution you have in mind should not
> change that behavior.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 6/14/2015 10:05 AM, Christian Carlow wrote:
> > Thanks Adrian and sorry for the misunderstanding, you are right grids
> > are rendered as tables.
> >
> > The embedded menu rendering functionality provided by Nicolas in
> > OFBIZ-6404 needs to be modified so that menus are rendered outside of
> > any forms that may be created for grid row submissions. As of right now
> > menus behave like edit fields and trigger the creation of an html form
> > element wrapper.
> >
> > I will patch OFBIZ-6404 so that menus always get rendered outside of row
> > edit forms in case of link-type="hidden-form". Then I will implement
> > screen and form/grid embedding in a similar manner.
> >
> > Thanks again for your help.
> >
> > On Sun, 2015-06-14 at 09:12 -0700, Adrian Crum wrote:
> >> I thought a grid is rendered as a <table> element, I was not aware that
> >> it is rendered as a <form> element.
> >>
> >> Grids do not support including screens. That feature was suggested
> >> before, and it would be a nice one to have. Actually, it would be nice
> >> if grid and form widgets worked more like the screen widget - with
> >> sections that can be controlled by conditional elements.
> >>
> >> Adrian Crum
> >> Sandglass Software
> >> www.sandglass-software.com
> >>
> >> On 6/14/2015 3:03 AM, Christian Carlow wrote:
> >>> Thanks for the feedback Adrian.
> >>>
> >>> I check commit logs and see the grid widget additions back in January
> >>> that you recommended using for OFBIZ-6402 which I did.
> >>>
> >>> But grids don't appear to support embedding of screens. Is this
> >>> something that is intended to be added later?
> >>>
> >>> If so, the difficulty is how to handle embedding of screens containing
> >>> forms when grid itself is already rendered as an html form element which
> >>> doesn't allow embedding of other form elements.
> >>>
> >>> This problem is demonstrated by OFBIZ-6404 where Nicolas added support
> >>> for menu embedding which only works if menu links are not rendered as
> >>> hidden forms. Whenever the embedded menus are rendered as hidden forms
> >>> the links no longer work.
> >>>
> >>> I found no grid widget JIRAs and therefore don't know how to proceed to
> >>> support screen widget embedding within a table list.
> >>>
> >>> I started implementing <iterate-table> based on <iterate-section> but
> >>> with <column> as the child elements as an alternate way to generate a
> >>> table list than with grid. This delivered the functionality I needed
> >>> but still needs improvements that seem redundantly supported by the grid
> >>> widget already, such as support for even and odd row coloring, column
> >>> titles etc.
> >>>
> >>> I'm trying to get some feedback as soon as possible so that I can make a
> >>> decision to continue on with the enhancements to <iterate-table> or to
> >>> abondon the <iterate-table> functionality already started and instead
> >>> pursue implementing screen embedding support for <grid>.
> >>>
> >>> For example:
> >>> <iterate-table entry="partyMap" list="partyMaps"
> >>> odd-row-style="alt-row">
> >>> <column title="${uiLabelMap.partyId}">
> >>> <label text="${partyMap.partyId}"
> >>> </column>
> >>> <column title="${uiLabelMap.partyAddress}">
> >>> <include-screen name="ViewPostalAddress"
> >>> location="component://party/widget/PartyScreens.xml"/>
> >>> </column>
> >>> </iterate-table>
> >>>
> >>> On Thu, 2015-06-11 at 23:10 -0700, Adrian Crum wrote:
> >>>> The grid widget is implemented. Please check the commit logs.
> >>>>
> >>>> The column widget is not intended to implement a grid. It is intended to
> >>>> be used for multi-column layout of screens (like newspaper columns).
> >>>>
> >>>> Adrian Crum
> >>>> Sandglass Software
> >>>> www.sandglass-software.com
> >>>>
> >>>> On 6/11/2015 2:57 PM, Christian Carlow wrote:
> >>>>> Adrian,
> >>>>>
> >>>>> So grid widget isn't implemented yet?
> >>>>>
> >>>>> Is there a JIRA for it?
> >>>>>
> >>>>> Would my proposal for <iterate-column> conflict with it's
> >>>>> implementation?
> >>>>>
> >>>>> If not, would <iterate-column> be worthy of a JIRA?
> >>>>>
> >>>>> On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
> >>>>>> The column widget is intended to be used for multi-column layout. It is
> >>>>>> not a replacement for a grid widget.
> >>>>>>
> >>>>>> Adrian Crum
> >>>>>> Sandglass Software
> >>>>>> www.sandglass-software.com
> >>>>>>
> >>>>>> On 6/11/2015 1:21 PM, Christian Carlow wrote:
> >>>>>>> <column-container> and <column> screen widgets seem to have been
> >>>>>>> implemented based on the discussion and JIRAs, but creating a single
> >>>>>>> table to contain a list doesn't seem supported for screens yet. The
> >>>>>>> following creates multiple tables for each <column-container>:
> >>>>>>>
> >>>>>>> <iterate-section>
> >>>>>>> <column-container>
> >>>>>>> <column>
> >>>>>>> </column>
> >>>>>>> </column-container>
> >>>>>>> </iterate-section>
> >>>>>>>
> >>>>>>> Should something like the following be supported to implement single
> >>>>>>> table functionality:
> >>>>>>>
> >>>>>>> <iterate-column list="listIt" style="basic-table" row-style="${groovy:
> >>>>>>> if(rowCount%2==0) 'alternate-row'}">
> >>>>>>> <column title="partyId">
> >>>>>>> </column>
> >>>>>>> <column title="partyName">
> >>>>>>> </column>
> >>>>>>> </iterate-column>
> >>>>>>>
> >>>>>>> Each iteration could create a row and row-style could be set using
> >>>>>>> FlexibleStringExpander for groovy conditions. <column-titles> would
> >>>>>>> create 1 extra row at the top which may be empty.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
> >>>>>>>> Thanks for the pointer Pierre.
> >>>>>>>>
> >>>>>>>> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
> >>>>>>>> being supported by the form menu embedding functionality because html
> >>>>>>>> forms cannot be nested. It seems the grid or column functionality will
> >>>>>>>> allow forms to be embedded in columns of table lists. Therefore
> >>>>>>>> OFBIZ-6404 probably isn't related since it implements a different
> >>>>>>>> approach to menu/form embedding.
> >>>>>>>>
> >>>>>>>> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
> >>>>>>>>> Various JIRA issues have been created, and several addressed/resolved. See
> >>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
> >>>>>>>>> (does not link all).
> >>>>>>>>>
> >>>>>>>>> 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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
> >>>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> What is the status of the grid widget enhancements discussed by Adrian
> >>>>>>>>>> and Gavin in this thread? Can other widgets be embedded within grids
> >>>>>>>>>> yet? Is Nicolas' enhancement allowing menus to be embedded as form
> >>>>>>>>>> fields of OFBIZ-6404 related to this?
> >>>>>>>>>>
> >>>>>>>>>> On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
> >
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
Keep in mind that menu items are rendered as forms for a reason - to
fight XSS attacks. So, whatever solution you have in mind should not
change that behavior.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 6/14/2015 10:05 AM, Christian Carlow wrote:
> Thanks Adrian and sorry for the misunderstanding, you are right grids
> are rendered as tables.
>
> The embedded menu rendering functionality provided by Nicolas in
> OFBIZ-6404 needs to be modified so that menus are rendered outside of
> any forms that may be created for grid row submissions. As of right now
> menus behave like edit fields and trigger the creation of an html form
> element wrapper.
>
> I will patch OFBIZ-6404 so that menus always get rendered outside of row
> edit forms in case of link-type="hidden-form". Then I will implement
> screen and form/grid embedding in a similar manner.
>
> Thanks again for your help.
>
> On Sun, 2015-06-14 at 09:12 -0700, Adrian Crum wrote:
>> I thought a grid is rendered as a <table> element, I was not aware that
>> it is rendered as a <form> element.
>>
>> Grids do not support including screens. That feature was suggested
>> before, and it would be a nice one to have. Actually, it would be nice
>> if grid and form widgets worked more like the screen widget - with
>> sections that can be controlled by conditional elements.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 6/14/2015 3:03 AM, Christian Carlow wrote:
>>> Thanks for the feedback Adrian.
>>>
>>> I check commit logs and see the grid widget additions back in January
>>> that you recommended using for OFBIZ-6402 which I did.
>>>
>>> But grids don't appear to support embedding of screens. Is this
>>> something that is intended to be added later?
>>>
>>> If so, the difficulty is how to handle embedding of screens containing
>>> forms when grid itself is already rendered as an html form element which
>>> doesn't allow embedding of other form elements.
>>>
>>> This problem is demonstrated by OFBIZ-6404 where Nicolas added support
>>> for menu embedding which only works if menu links are not rendered as
>>> hidden forms. Whenever the embedded menus are rendered as hidden forms
>>> the links no longer work.
>>>
>>> I found no grid widget JIRAs and therefore don't know how to proceed to
>>> support screen widget embedding within a table list.
>>>
>>> I started implementing <iterate-table> based on <iterate-section> but
>>> with <column> as the child elements as an alternate way to generate a
>>> table list than with grid. This delivered the functionality I needed
>>> but still needs improvements that seem redundantly supported by the grid
>>> widget already, such as support for even and odd row coloring, column
>>> titles etc.
>>>
>>> I'm trying to get some feedback as soon as possible so that I can make a
>>> decision to continue on with the enhancements to <iterate-table> or to
>>> abondon the <iterate-table> functionality already started and instead
>>> pursue implementing screen embedding support for <grid>.
>>>
>>> For example:
>>> <iterate-table entry="partyMap" list="partyMaps"
>>> odd-row-style="alt-row">
>>> <column title="${uiLabelMap.partyId}">
>>> <label text="${partyMap.partyId}"
>>> </column>
>>> <column title="${uiLabelMap.partyAddress}">
>>> <include-screen name="ViewPostalAddress"
>>> location="component://party/widget/PartyScreens.xml"/>
>>> </column>
>>> </iterate-table>
>>>
>>> On Thu, 2015-06-11 at 23:10 -0700, Adrian Crum wrote:
>>>> The grid widget is implemented. Please check the commit logs.
>>>>
>>>> The column widget is not intended to implement a grid. It is intended to
>>>> be used for multi-column layout of screens (like newspaper columns).
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 6/11/2015 2:57 PM, Christian Carlow wrote:
>>>>> Adrian,
>>>>>
>>>>> So grid widget isn't implemented yet?
>>>>>
>>>>> Is there a JIRA for it?
>>>>>
>>>>> Would my proposal for <iterate-column> conflict with it's
>>>>> implementation?
>>>>>
>>>>> If not, would <iterate-column> be worthy of a JIRA?
>>>>>
>>>>> On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
>>>>>> The column widget is intended to be used for multi-column layout. It is
>>>>>> not a replacement for a grid widget.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 6/11/2015 1:21 PM, Christian Carlow wrote:
>>>>>>> <column-container> and <column> screen widgets seem to have been
>>>>>>> implemented based on the discussion and JIRAs, but creating a single
>>>>>>> table to contain a list doesn't seem supported for screens yet. The
>>>>>>> following creates multiple tables for each <column-container>:
>>>>>>>
>>>>>>> <iterate-section>
>>>>>>> <column-container>
>>>>>>> <column>
>>>>>>> </column>
>>>>>>> </column-container>
>>>>>>> </iterate-section>
>>>>>>>
>>>>>>> Should something like the following be supported to implement single
>>>>>>> table functionality:
>>>>>>>
>>>>>>> <iterate-column list="listIt" style="basic-table" row-style="${groovy:
>>>>>>> if(rowCount%2==0) 'alternate-row'}">
>>>>>>> <column title="partyId">
>>>>>>> </column>
>>>>>>> <column title="partyName">
>>>>>>> </column>
>>>>>>> </iterate-column>
>>>>>>>
>>>>>>> Each iteration could create a row and row-style could be set using
>>>>>>> FlexibleStringExpander for groovy conditions. <column-titles> would
>>>>>>> create 1 extra row at the top which may be empty.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
>>>>>>>> Thanks for the pointer Pierre.
>>>>>>>>
>>>>>>>> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
>>>>>>>> being supported by the form menu embedding functionality because html
>>>>>>>> forms cannot be nested. It seems the grid or column functionality will
>>>>>>>> allow forms to be embedded in columns of table lists. Therefore
>>>>>>>> OFBIZ-6404 probably isn't related since it implements a different
>>>>>>>> approach to menu/form embedding.
>>>>>>>>
>>>>>>>> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
>>>>>>>>> Various JIRA issues have been created, and several addressed/resolved. See
>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
>>>>>>>>> (does not link all).
>>>>>>>>>
>>>>>>>>> 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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> What is the status of the grid widget enhancements discussed by Adrian
>>>>>>>>>> and Gavin in this thread? Can other widgets be embedded within grids
>>>>>>>>>> yet? Is Nicolas' enhancement allowing menus to be embedded as form
>>>>>>>>>> fields of OFBIZ-6404 related to this?
>>>>>>>>>>
>>>>>>>>>> On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Widget Overhaul
Posted by Christian Carlow <ch...@gmail.com>.
Thanks Adrian and sorry for the misunderstanding, you are right grids
are rendered as tables.
The embedded menu rendering functionality provided by Nicolas in
OFBIZ-6404 needs to be modified so that menus are rendered outside of
any forms that may be created for grid row submissions. As of right now
menus behave like edit fields and trigger the creation of an html form
element wrapper.
I will patch OFBIZ-6404 so that menus always get rendered outside of row
edit forms in case of link-type="hidden-form". Then I will implement
screen and form/grid embedding in a similar manner.
Thanks again for your help.
On Sun, 2015-06-14 at 09:12 -0700, Adrian Crum wrote:
> I thought a grid is rendered as a <table> element, I was not aware that
> it is rendered as a <form> element.
>
> Grids do not support including screens. That feature was suggested
> before, and it would be a nice one to have. Actually, it would be nice
> if grid and form widgets worked more like the screen widget - with
> sections that can be controlled by conditional elements.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 6/14/2015 3:03 AM, Christian Carlow wrote:
> > Thanks for the feedback Adrian.
> >
> > I check commit logs and see the grid widget additions back in January
> > that you recommended using for OFBIZ-6402 which I did.
> >
> > But grids don't appear to support embedding of screens. Is this
> > something that is intended to be added later?
> >
> > If so, the difficulty is how to handle embedding of screens containing
> > forms when grid itself is already rendered as an html form element which
> > doesn't allow embedding of other form elements.
> >
> > This problem is demonstrated by OFBIZ-6404 where Nicolas added support
> > for menu embedding which only works if menu links are not rendered as
> > hidden forms. Whenever the embedded menus are rendered as hidden forms
> > the links no longer work.
> >
> > I found no grid widget JIRAs and therefore don't know how to proceed to
> > support screen widget embedding within a table list.
> >
> > I started implementing <iterate-table> based on <iterate-section> but
> > with <column> as the child elements as an alternate way to generate a
> > table list than with grid. This delivered the functionality I needed
> > but still needs improvements that seem redundantly supported by the grid
> > widget already, such as support for even and odd row coloring, column
> > titles etc.
> >
> > I'm trying to get some feedback as soon as possible so that I can make a
> > decision to continue on with the enhancements to <iterate-table> or to
> > abondon the <iterate-table> functionality already started and instead
> > pursue implementing screen embedding support for <grid>.
> >
> > For example:
> > <iterate-table entry="partyMap" list="partyMaps"
> > odd-row-style="alt-row">
> > <column title="${uiLabelMap.partyId}">
> > <label text="${partyMap.partyId}"
> > </column>
> > <column title="${uiLabelMap.partyAddress}">
> > <include-screen name="ViewPostalAddress"
> > location="component://party/widget/PartyScreens.xml"/>
> > </column>
> > </iterate-table>
> >
> > On Thu, 2015-06-11 at 23:10 -0700, Adrian Crum wrote:
> >> The grid widget is implemented. Please check the commit logs.
> >>
> >> The column widget is not intended to implement a grid. It is intended to
> >> be used for multi-column layout of screens (like newspaper columns).
> >>
> >> Adrian Crum
> >> Sandglass Software
> >> www.sandglass-software.com
> >>
> >> On 6/11/2015 2:57 PM, Christian Carlow wrote:
> >>> Adrian,
> >>>
> >>> So grid widget isn't implemented yet?
> >>>
> >>> Is there a JIRA for it?
> >>>
> >>> Would my proposal for <iterate-column> conflict with it's
> >>> implementation?
> >>>
> >>> If not, would <iterate-column> be worthy of a JIRA?
> >>>
> >>> On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
> >>>> The column widget is intended to be used for multi-column layout. It is
> >>>> not a replacement for a grid widget.
> >>>>
> >>>> Adrian Crum
> >>>> Sandglass Software
> >>>> www.sandglass-software.com
> >>>>
> >>>> On 6/11/2015 1:21 PM, Christian Carlow wrote:
> >>>>> <column-container> and <column> screen widgets seem to have been
> >>>>> implemented based on the discussion and JIRAs, but creating a single
> >>>>> table to contain a list doesn't seem supported for screens yet. The
> >>>>> following creates multiple tables for each <column-container>:
> >>>>>
> >>>>> <iterate-section>
> >>>>> <column-container>
> >>>>> <column>
> >>>>> </column>
> >>>>> </column-container>
> >>>>> </iterate-section>
> >>>>>
> >>>>> Should something like the following be supported to implement single
> >>>>> table functionality:
> >>>>>
> >>>>> <iterate-column list="listIt" style="basic-table" row-style="${groovy:
> >>>>> if(rowCount%2==0) 'alternate-row'}">
> >>>>> <column title="partyId">
> >>>>> </column>
> >>>>> <column title="partyName">
> >>>>> </column>
> >>>>> </iterate-column>
> >>>>>
> >>>>> Each iteration could create a row and row-style could be set using
> >>>>> FlexibleStringExpander for groovy conditions. <column-titles> would
> >>>>> create 1 extra row at the top which may be empty.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
> >>>>>> Thanks for the pointer Pierre.
> >>>>>>
> >>>>>> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
> >>>>>> being supported by the form menu embedding functionality because html
> >>>>>> forms cannot be nested. It seems the grid or column functionality will
> >>>>>> allow forms to be embedded in columns of table lists. Therefore
> >>>>>> OFBIZ-6404 probably isn't related since it implements a different
> >>>>>> approach to menu/form embedding.
> >>>>>>
> >>>>>> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
> >>>>>>> Various JIRA issues have been created, and several addressed/resolved. See
> >>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
> >>>>>>> (does not link all).
> >>>>>>>
> >>>>>>> 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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
> >>>>>>>> wrote:
> >>>>>>>
> >>>>>>>> What is the status of the grid widget enhancements discussed by Adrian
> >>>>>>>> and Gavin in this thread? Can other widgets be embedded within grids
> >>>>>>>> yet? Is Nicolas' enhancement allowing menus to be embedded as form
> >>>>>>>> fields of OFBIZ-6404 related to this?
> >>>>>>>>
> >>>>>>>> On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
> >
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
I thought a grid is rendered as a <table> element, I was not aware that
it is rendered as a <form> element.
Grids do not support including screens. That feature was suggested
before, and it would be a nice one to have. Actually, it would be nice
if grid and form widgets worked more like the screen widget - with
sections that can be controlled by conditional elements.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 6/14/2015 3:03 AM, Christian Carlow wrote:
> Thanks for the feedback Adrian.
>
> I check commit logs and see the grid widget additions back in January
> that you recommended using for OFBIZ-6402 which I did.
>
> But grids don't appear to support embedding of screens. Is this
> something that is intended to be added later?
>
> If so, the difficulty is how to handle embedding of screens containing
> forms when grid itself is already rendered as an html form element which
> doesn't allow embedding of other form elements.
>
> This problem is demonstrated by OFBIZ-6404 where Nicolas added support
> for menu embedding which only works if menu links are not rendered as
> hidden forms. Whenever the embedded menus are rendered as hidden forms
> the links no longer work.
>
> I found no grid widget JIRAs and therefore don't know how to proceed to
> support screen widget embedding within a table list.
>
> I started implementing <iterate-table> based on <iterate-section> but
> with <column> as the child elements as an alternate way to generate a
> table list than with grid. This delivered the functionality I needed
> but still needs improvements that seem redundantly supported by the grid
> widget already, such as support for even and odd row coloring, column
> titles etc.
>
> I'm trying to get some feedback as soon as possible so that I can make a
> decision to continue on with the enhancements to <iterate-table> or to
> abondon the <iterate-table> functionality already started and instead
> pursue implementing screen embedding support for <grid>.
>
> For example:
> <iterate-table entry="partyMap" list="partyMaps"
> odd-row-style="alt-row">
> <column title="${uiLabelMap.partyId}">
> <label text="${partyMap.partyId}"
> </column>
> <column title="${uiLabelMap.partyAddress}">
> <include-screen name="ViewPostalAddress"
> location="component://party/widget/PartyScreens.xml"/>
> </column>
> </iterate-table>
>
> On Thu, 2015-06-11 at 23:10 -0700, Adrian Crum wrote:
>> The grid widget is implemented. Please check the commit logs.
>>
>> The column widget is not intended to implement a grid. It is intended to
>> be used for multi-column layout of screens (like newspaper columns).
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 6/11/2015 2:57 PM, Christian Carlow wrote:
>>> Adrian,
>>>
>>> So grid widget isn't implemented yet?
>>>
>>> Is there a JIRA for it?
>>>
>>> Would my proposal for <iterate-column> conflict with it's
>>> implementation?
>>>
>>> If not, would <iterate-column> be worthy of a JIRA?
>>>
>>> On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
>>>> The column widget is intended to be used for multi-column layout. It is
>>>> not a replacement for a grid widget.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 6/11/2015 1:21 PM, Christian Carlow wrote:
>>>>> <column-container> and <column> screen widgets seem to have been
>>>>> implemented based on the discussion and JIRAs, but creating a single
>>>>> table to contain a list doesn't seem supported for screens yet. The
>>>>> following creates multiple tables for each <column-container>:
>>>>>
>>>>> <iterate-section>
>>>>> <column-container>
>>>>> <column>
>>>>> </column>
>>>>> </column-container>
>>>>> </iterate-section>
>>>>>
>>>>> Should something like the following be supported to implement single
>>>>> table functionality:
>>>>>
>>>>> <iterate-column list="listIt" style="basic-table" row-style="${groovy:
>>>>> if(rowCount%2==0) 'alternate-row'}">
>>>>> <column title="partyId">
>>>>> </column>
>>>>> <column title="partyName">
>>>>> </column>
>>>>> </iterate-column>
>>>>>
>>>>> Each iteration could create a row and row-style could be set using
>>>>> FlexibleStringExpander for groovy conditions. <column-titles> would
>>>>> create 1 extra row at the top which may be empty.
>>>>>
>>>>>
>>>>>
>>>>> On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
>>>>>> Thanks for the pointer Pierre.
>>>>>>
>>>>>> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
>>>>>> being supported by the form menu embedding functionality because html
>>>>>> forms cannot be nested. It seems the grid or column functionality will
>>>>>> allow forms to be embedded in columns of table lists. Therefore
>>>>>> OFBIZ-6404 probably isn't related since it implements a different
>>>>>> approach to menu/form embedding.
>>>>>>
>>>>>> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
>>>>>>> Various JIRA issues have been created, and several addressed/resolved. See
>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
>>>>>>> (does not link all).
>>>>>>>
>>>>>>> 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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> What is the status of the grid widget enhancements discussed by Adrian
>>>>>>>> and Gavin in this thread? Can other widgets be embedded within grids
>>>>>>>> yet? Is Nicolas' enhancement allowing menus to be embedded as form
>>>>>>>> fields of OFBIZ-6404 related to this?
>>>>>>>>
>>>>>>>> On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Widget Overhaul
Posted by Christian Carlow <ch...@gmail.com>.
Thanks for the feedback Adrian.
I check commit logs and see the grid widget additions back in January
that you recommended using for OFBIZ-6402 which I did.
But grids don't appear to support embedding of screens. Is this
something that is intended to be added later?
If so, the difficulty is how to handle embedding of screens containing
forms when grid itself is already rendered as an html form element which
doesn't allow embedding of other form elements.
This problem is demonstrated by OFBIZ-6404 where Nicolas added support
for menu embedding which only works if menu links are not rendered as
hidden forms. Whenever the embedded menus are rendered as hidden forms
the links no longer work.
I found no grid widget JIRAs and therefore don't know how to proceed to
support screen widget embedding within a table list.
I started implementing <iterate-table> based on <iterate-section> but
with <column> as the child elements as an alternate way to generate a
table list than with grid. This delivered the functionality I needed
but still needs improvements that seem redundantly supported by the grid
widget already, such as support for even and odd row coloring, column
titles etc.
I'm trying to get some feedback as soon as possible so that I can make a
decision to continue on with the enhancements to <iterate-table> or to
abondon the <iterate-table> functionality already started and instead
pursue implementing screen embedding support for <grid>.
For example:
<iterate-table entry="partyMap" list="partyMaps"
odd-row-style="alt-row">
<column title="${uiLabelMap.partyId}">
<label text="${partyMap.partyId}"
</column>
<column title="${uiLabelMap.partyAddress}">
<include-screen name="ViewPostalAddress"
location="component://party/widget/PartyScreens.xml"/>
</column>
</iterate-table>
On Thu, 2015-06-11 at 23:10 -0700, Adrian Crum wrote:
> The grid widget is implemented. Please check the commit logs.
>
> The column widget is not intended to implement a grid. It is intended to
> be used for multi-column layout of screens (like newspaper columns).
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 6/11/2015 2:57 PM, Christian Carlow wrote:
> > Adrian,
> >
> > So grid widget isn't implemented yet?
> >
> > Is there a JIRA for it?
> >
> > Would my proposal for <iterate-column> conflict with it's
> > implementation?
> >
> > If not, would <iterate-column> be worthy of a JIRA?
> >
> > On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
> >> The column widget is intended to be used for multi-column layout. It is
> >> not a replacement for a grid widget.
> >>
> >> Adrian Crum
> >> Sandglass Software
> >> www.sandglass-software.com
> >>
> >> On 6/11/2015 1:21 PM, Christian Carlow wrote:
> >>> <column-container> and <column> screen widgets seem to have been
> >>> implemented based on the discussion and JIRAs, but creating a single
> >>> table to contain a list doesn't seem supported for screens yet. The
> >>> following creates multiple tables for each <column-container>:
> >>>
> >>> <iterate-section>
> >>> <column-container>
> >>> <column>
> >>> </column>
> >>> </column-container>
> >>> </iterate-section>
> >>>
> >>> Should something like the following be supported to implement single
> >>> table functionality:
> >>>
> >>> <iterate-column list="listIt" style="basic-table" row-style="${groovy:
> >>> if(rowCount%2==0) 'alternate-row'}">
> >>> <column title="partyId">
> >>> </column>
> >>> <column title="partyName">
> >>> </column>
> >>> </iterate-column>
> >>>
> >>> Each iteration could create a row and row-style could be set using
> >>> FlexibleStringExpander for groovy conditions. <column-titles> would
> >>> create 1 extra row at the top which may be empty.
> >>>
> >>>
> >>>
> >>> On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
> >>>> Thanks for the pointer Pierre.
> >>>>
> >>>> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
> >>>> being supported by the form menu embedding functionality because html
> >>>> forms cannot be nested. It seems the grid or column functionality will
> >>>> allow forms to be embedded in columns of table lists. Therefore
> >>>> OFBIZ-6404 probably isn't related since it implements a different
> >>>> approach to menu/form embedding.
> >>>>
> >>>> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
> >>>>> Various JIRA issues have been created, and several addressed/resolved. See
> >>>>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
> >>>>> (does not link all).
> >>>>>
> >>>>> 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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
> >>>>>> wrote:
> >>>>>
> >>>>>> What is the status of the grid widget enhancements discussed by Adrian
> >>>>>> and Gavin in this thread? Can other widgets be embedded within grids
> >>>>>> yet? Is Nicolas' enhancement allowing menus to be embedded as form
> >>>>>> fields of OFBIZ-6404 related to this?
> >>>>>>
> >>>>>> On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >
> >
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
The grid widget is implemented. Please check the commit logs.
The column widget is not intended to implement a grid. It is intended to
be used for multi-column layout of screens (like newspaper columns).
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 6/11/2015 2:57 PM, Christian Carlow wrote:
> Adrian,
>
> So grid widget isn't implemented yet?
>
> Is there a JIRA for it?
>
> Would my proposal for <iterate-column> conflict with it's
> implementation?
>
> If not, would <iterate-column> be worthy of a JIRA?
>
> On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
>> The column widget is intended to be used for multi-column layout. It is
>> not a replacement for a grid widget.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 6/11/2015 1:21 PM, Christian Carlow wrote:
>>> <column-container> and <column> screen widgets seem to have been
>>> implemented based on the discussion and JIRAs, but creating a single
>>> table to contain a list doesn't seem supported for screens yet. The
>>> following creates multiple tables for each <column-container>:
>>>
>>> <iterate-section>
>>> <column-container>
>>> <column>
>>> </column>
>>> </column-container>
>>> </iterate-section>
>>>
>>> Should something like the following be supported to implement single
>>> table functionality:
>>>
>>> <iterate-column list="listIt" style="basic-table" row-style="${groovy:
>>> if(rowCount%2==0) 'alternate-row'}">
>>> <column title="partyId">
>>> </column>
>>> <column title="partyName">
>>> </column>
>>> </iterate-column>
>>>
>>> Each iteration could create a row and row-style could be set using
>>> FlexibleStringExpander for groovy conditions. <column-titles> would
>>> create 1 extra row at the top which may be empty.
>>>
>>>
>>>
>>> On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
>>>> Thanks for the pointer Pierre.
>>>>
>>>> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
>>>> being supported by the form menu embedding functionality because html
>>>> forms cannot be nested. It seems the grid or column functionality will
>>>> allow forms to be embedded in columns of table lists. Therefore
>>>> OFBIZ-6404 probably isn't related since it implements a different
>>>> approach to menu/form embedding.
>>>>
>>>> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
>>>>> Various JIRA issues have been created, and several addressed/resolved. See
>>>>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
>>>>> (does not link all).
>>>>>
>>>>> 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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
>>>>>> wrote:
>>>>>
>>>>>> What is the status of the grid widget enhancements discussed by Adrian
>>>>>> and Gavin in this thread? Can other widgets be embedded within grids
>>>>>> yet? Is Nicolas' enhancement allowing menus to be embedded as form
>>>>>> fields of OFBIZ-6404 related to this?
>>>>>>
>>>>>> On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>
>
Re: Widget Overhaul
Posted by Christian Carlow <ch...@gmail.com>.
Adrian,
So grid widget isn't implemented yet?
Is there a JIRA for it?
Would my proposal for <iterate-column> conflict with it's
implementation?
If not, would <iterate-column> be worthy of a JIRA?
On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
> The column widget is intended to be used for multi-column layout. It is
> not a replacement for a grid widget.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 6/11/2015 1:21 PM, Christian Carlow wrote:
> > <column-container> and <column> screen widgets seem to have been
> > implemented based on the discussion and JIRAs, but creating a single
> > table to contain a list doesn't seem supported for screens yet. The
> > following creates multiple tables for each <column-container>:
> >
> > <iterate-section>
> > <column-container>
> > <column>
> > </column>
> > </column-container>
> > </iterate-section>
> >
> > Should something like the following be supported to implement single
> > table functionality:
> >
> > <iterate-column list="listIt" style="basic-table" row-style="${groovy:
> > if(rowCount%2==0) 'alternate-row'}">
> > <column title="partyId">
> > </column>
> > <column title="partyName">
> > </column>
> > </iterate-column>
> >
> > Each iteration could create a row and row-style could be set using
> > FlexibleStringExpander for groovy conditions. <column-titles> would
> > create 1 extra row at the top which may be empty.
> >
> >
> >
> > On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
> >> Thanks for the pointer Pierre.
> >>
> >> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
> >> being supported by the form menu embedding functionality because html
> >> forms cannot be nested. It seems the grid or column functionality will
> >> allow forms to be embedded in columns of table lists. Therefore
> >> OFBIZ-6404 probably isn't related since it implements a different
> >> approach to menu/form embedding.
> >>
> >> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
> >>> Various JIRA issues have been created, and several addressed/resolved. See
> >>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
> >>> (does not link all).
> >>>
> >>> 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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
> >>>> wrote:
> >>>
> >>>> What is the status of the grid widget enhancements discussed by Adrian
> >>>> and Gavin in this thread? Can other widgets be embedded within grids
> >>>> yet? Is Nicolas' enhancement allowing menus to be embedded as form
> >>>> fields of OFBIZ-6404 related to this?
> >>>>
> >>>> On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
The column widget is intended to be used for multi-column layout. It is
not a replacement for a grid widget.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 6/11/2015 1:21 PM, Christian Carlow wrote:
> <column-container> and <column> screen widgets seem to have been
> implemented based on the discussion and JIRAs, but creating a single
> table to contain a list doesn't seem supported for screens yet. The
> following creates multiple tables for each <column-container>:
>
> <iterate-section>
> <column-container>
> <column>
> </column>
> </column-container>
> </iterate-section>
>
> Should something like the following be supported to implement single
> table functionality:
>
> <iterate-column list="listIt" style="basic-table" row-style="${groovy:
> if(rowCount%2==0) 'alternate-row'}">
> <column title="partyId">
> </column>
> <column title="partyName">
> </column>
> </iterate-column>
>
> Each iteration could create a row and row-style could be set using
> FlexibleStringExpander for groovy conditions. <column-titles> would
> create 1 extra row at the top which may be empty.
>
>
>
> On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
>> Thanks for the pointer Pierre.
>>
>> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
>> being supported by the form menu embedding functionality because html
>> forms cannot be nested. It seems the grid or column functionality will
>> allow forms to be embedded in columns of table lists. Therefore
>> OFBIZ-6404 probably isn't related since it implements a different
>> approach to menu/form embedding.
>>
>> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
>>> Various JIRA issues have been created, and several addressed/resolved. See
>>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
>>> (does not link all).
>>>
>>> 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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
>>>> wrote:
>>>
>>>> What is the status of the grid widget enhancements discussed by Adrian
>>>> and Gavin in this thread? Can other widgets be embedded within grids
>>>> yet? Is Nicolas' enhancement allowing menus to be embedded as form
>>>> fields of OFBIZ-6404 related to this?
>>>>
>>>> On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>
>>
>
>
Re: Widget Overhaul
Posted by Christian Carlow <ch...@gmail.com>.
<column-container> and <column> screen widgets seem to have been
implemented based on the discussion and JIRAs, but creating a single
table to contain a list doesn't seem supported for screens yet. The
following creates multiple tables for each <column-container>:
<iterate-section>
<column-container>
<column>
</column>
</column-container>
</iterate-section>
Should something like the following be supported to implement single
table functionality:
<iterate-column list="listIt" style="basic-table" row-style="${groovy:
if(rowCount%2==0) 'alternate-row'}">
<column title="partyId">
</column>
<column title="partyName">
</column>
</iterate-column>
Each iteration could create a row and row-style could be set using
FlexibleStringExpander for groovy conditions. <column-titles> would
create 1 extra row at the top which may be empty.
On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
> Thanks for the pointer Pierre.
>
> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
> being supported by the form menu embedding functionality because html
> forms cannot be nested. It seems the grid or column functionality will
> allow forms to be embedded in columns of table lists. Therefore
> OFBIZ-6404 probably isn't related since it implements a different
> approach to menu/form embedding.
>
> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
> > Various JIRA issues have been created, and several addressed/resolved. See
> > https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
> > (does not link all).
> >
> > 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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
> > > wrote:
> >
> > > What is the status of the grid widget enhancements discussed by Adrian
> > > and Gavin in this thread? Can other widgets be embedded within grids
> > > yet? Is Nicolas' enhancement allowing menus to be embedded as form
> > > fields of OFBIZ-6404 related to this?
> > >
> > > On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>
> > >
> > >
> > >
>
>
Re: Widget Overhaul
Posted by Christian Carlow <ch...@gmail.com>.
Thanks for the pointer Pierre.
I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
being supported by the form menu embedding functionality because html
forms cannot be nested. It seems the grid or column functionality will
allow forms to be embedded in columns of table lists. Therefore
OFBIZ-6404 probably isn't related since it implements a different
approach to menu/form embedding.
On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
> Various JIRA issues have been created, and several addressed/resolved. See
> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
> (does not link all).
>
> 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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
> > wrote:
>
> > What is the status of the grid widget enhancements discussed by Adrian
> > and Gavin in this thread? Can other widgets be embedded within grids
> > yet? Is Nicolas' enhancement allowing menus to be embedded as form
> > fields of OFBIZ-6404 related to this?
> >
> > On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>
> >
> >
> >
Re: Widget Overhaul
Posted by Pierre Smits <pi...@gmail.com>.
Various JIRA issues have been created, and several addressed/resolved. See
https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
(does not link all).
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 Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.carlow@gmail.com
> wrote:
> What is the status of the grid widget enhancements discussed by Adrian
> and Gavin in this thread? Can other widgets be embedded within grids
> yet? Is Nicolas' enhancement allowing menus to be embedded as form
> fields of OFBIZ-6404 related to this?
>
> On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>
>
>
>
Re: Widget Overhaul
Posted by Christian Carlow <ch...@gmail.com>.
What is the status of the grid widget enhancements discussed by Adrian
and Gavin in this thread? Can other widgets be embedded within grids
yet? Is Nicolas' enhancement allowing menus to be embedded as form
fields of OFBIZ-6404 related to this?
On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie 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.crum@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.crum@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.crum@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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
Re: Widget Overhaul
Posted by Pierre Smits <pi...@gmail.com>.
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 <pi...@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.crum@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 <kw...@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.crum@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.crum@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.crum@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>
Re: Widget Overhaul
Posted by Pierre Smits <pi...@gmail.com>.
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.crum@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 <pi...@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 <pi...@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.crum@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.crum@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 <kw...@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.crum@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.crum@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.crum@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
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 <pi...@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 <pi...@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.crum@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.crum@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 <kw...@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.crum@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.crum@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.crum@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
Re: Widget Overhaul
Posted by Pierre Smits <pi...@gmail.com>.
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 <pi...@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 <pi...@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.crum@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.crum@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 <kw...@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.crum@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.crum@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.crum@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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
Re: Widget Overhaul
Posted by Pierre Smits <pi...@gmail.com>.
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 <pi...@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.crum@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.crum@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 <kw...@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.crum@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.crum@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.crum@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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>
Re: Widget Overhaul
Posted by Pierre Smits <pi...@gmail.com>.
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.crum@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.crum@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 <kw...@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.crum@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.crum@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.crum@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
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.crum@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 <kw...@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.crum@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.crum@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.crum@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>
Re: Widget Overhaul
Posted by Pierre Smits <pi...@gmail.com>.
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.crum@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 <kw...@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.crum@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.crum@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.crum@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
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 <kw...@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.crum@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.crum@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.crum@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
Re: Widget Overhaul
Posted by Pierre Smits <pi...@gmail.com>.
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 <kw...@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.crum@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.crum@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.crum@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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
>
Re: Widget Overhaul
Posted by Gavin Mabie <kw...@gmail.com>.
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.crum@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.crum@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.crum@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
>>>>>
>>>>>
>>>>>
>>>>
>>
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
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.crum@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.crum@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
>>>>
>>>>
>>>
>
Re: Widget Overhaul
Posted by Gavin Mabie <kw...@gmail.com>.
With columns already existing, rendering them inside rows would constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum <
adrian.crum@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.crum@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
>>>
>>>
>>
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
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.crum@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
>>
>
Re: Widget Overhaul
Posted by Gavin Mabie <kw...@gmail.com>.
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.crum@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
>
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
Exactly. I would like to wait a few months to make sure all issues have
surfaced and have been fixed.
Btw, I apologize for all of the recent bugs resulting from the refactor.
I had done some work on it on one weekend, and then set it aside. When I
returned to it the next weekend, I thought it was ready for committing
and I committed it, but later I realized I did not test the changes yet.
So I unintentionally committed untested code.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 2/5/2015 12:26 AM, Jacques Le Roux wrote:
> I would though wait that all the possibly related opened Jiras will be
> fixed. Some projects are based on the R14.12 branch and people expect
> this branch to be stable even if not yet released.
>
> Jacques
>
> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>> On Jan 17, 2015, at 11:16 PM, Adrian Crum
>> <ad...@sandglass-software.com> wrote:
>>
>>> After all of this work is completed, I would like to backport it to
>>> the R14 branch.
>> Hi Adrian,
>>
>> I just wanted to mention that I agree that we should backport all this
>> work to the 14.12 branch, which is pretty new and still needs to
>> undergo to the stabilization process: in this way it will be easier to
>> maintain it (by backporting the fixes) in the future years.
>>
>> Jacopo
>>
Re: Release policy
Posted by Ron Wheeler <rw...@artifact-software.com>.
+1
We should be careful about adding things to the project infrastructure.
If it will not be kept up to date, don't add it into the main sections.
Things that are private musings or a best partial specifications of a
potential enhancement should be clearly marked as such and kept out of
the view of someone trying to get started with OFBiz.
The current effort should help identify and clean up the important items
and move old stuff to the archives.
We can be a bit ruthless since nothing is really lost forever.
Ron
On 12/02/2015 2:40 AM, Jacques Le Roux wrote:
> This is something I really want to do now, I will try to remove as
> much as possible things from Confluence!
>
> Jacques
>
> Le 11/02/2015 23:23, Jacques Le Roux a écrit :
>> Actually it's more simple than that. It's explained in the Download
>> page and there is also a README in the "OFBiz root (folder)"
>> Maybe we should think otherwise and remove all things in the wiki
>> which might not been ALWAYS maintained.
>> From this conversation I begin to wonder if it's not the right
>> solution. Keep the documentation as simple as possible!
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Release policy
Posted by Jacques Le Roux <ja...@les7arts.com>.
This is something I really want to do now, I will try to remove as much as possible things from Confluence!
Jacques
Le 11/02/2015 23:23, Jacques Le Roux a écrit :
> Actually it's more simple than that. It's explained in the Download page and there is also a README in the "OFBiz root (folder)"
> Maybe we should think otherwise and remove all things in the wiki which might not been ALWAYS maintained.
> From this conversation I begin to wonder if it's not the right solution. Keep the documentation as simple as possible!
Re: Release policy
Posted by Jacques Le Roux <ja...@les7arts.com>.
BTW, I think suggested a wrong page to put the rules, better to use
https://cwiki.apache.org/confluence/display/OFBADMIN/Release+Plan
BTW why both?
https://cwiki.apache.org/confluence/display/OFBADMIN/Release+Management+Guide+for+OFBiz
https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Release+Management+Roadmap
While at it, we could maybe get rid (or archive?) of
https://cwiki.apache.org/confluence/display/OFBADMIN/Press+Releases and children. Reasons: we don't need to keep widely broadcasted information and
next releases did not follow this pattern
https://cwiki.apache.org/confluence/display/OFBADMIN/Announcement+for+new+release+Apache+OFBiz+09.04.01
https://cwiki.apache.org/confluence/display/OFBADMIN/Announcement+for+new+release+Apache+OFBiz+10.04
https://cwiki.apache.org/confluence/display/OFBADMIN/Press+Release+for+Release+Branch+9.4
Jacques
Le 12/02/2015 01:31, Ron Wheeler a écrit :
> It is getting a bit long so I will make my comments at the top.
>
> What is the plan for the next release?
> Will it be 13.07.02 or 14.12.01?
There is no plan yet
>
> Who is the project manager for the release project?
For the moment Jacopo insisted to always be the RM
>
> What has to be done to get it finalized?
>
> What help is required? How do people sign up to help?
>
> Is there going to be a meeting to kick off the process?
I don't know
Jacques
>
> Ron
>
> On 11/02/2015 5:23 PM, Jacques Le Roux wrote:
>>
>> Le 11/02/2015 21:14, Ron Wheeler a écrit :
>>> On 11/02/2015 1:56 PM, Jacques Le Roux wrote:
>>>>
>>>> Le 09/02/2015 15:10, Ron Wheeler a écrit :
>>>>> On 09/02/2015 5:21 AM, Jacques Le Roux wrote:
>>>>>>
>>>>>> Le 06/02/2015 17:27, Ron Wheeler a écrit :
>>>>>>>
>>>>>>> I would like to see more releases with smaller deltas so that the trunk can be a bit more open to work where mistakes are not so critical and
>>>>>>> cause so much grief since SI's will not feel that they have to fork the trunk to get their customers a working product.
>>>>>>
>>>>>> I believe people should rather user the last release branch than forking trunk or such
>>>>>>
>>>>>>> Security bugs need to be fixed, backported to all supported versions and released before the exploit becomes public knowledge.
>>>>>>>
>>>>>>> This means that there must be an agile release process if you want end-users to feel comfortable that their core data can be secure while
>>>>>>> using OFBiz.
>>>>>>
>>>>>> What does mean "agile" here for you?
>>>>> I do not have specific criteria in mind.
>>>>> If the integrity of OFBiz data or business processes is at risk from a security problem that has been raised in a JIRA, diagnosed, fixed and
>>>>> advertised to the hacker community through the forum and JIRA, it would be a good idea to issue a release and suggest that people upgrade or
>>>>> issue an upgrade that can safely be applied by end-users to their system ASAP.
>>>>> Waiting for a year to issue a new release is not sufficiently agile and I would expect a gradual improvement in the responsiveness over time.
>>>>> I am not sure how many security patches get issued each year and how they are currently identified and tracked by the PMC.
>>>>
>>>> I thought you were not specifically speaking about security problems. Anyway, it's not done that way. Roughly: someone (a white-hat hacker) find
>>>> an issue in OFBiz and report to the ASF security team http://www.apache.org/security/ (or rarely directly to the PMC, in private ML, so can't be
>>>> read but by PMC members). The ASF security team then send the information to the PMC. The PMC fixes the issues ASAP. Then this issue is fixed in
>>>> trunk and backported in all living branches in a shoot, a new release is created and a CVE https://cve.mitre.org/ created. Then the OFBiz
>>>> Download page is updated
>>> How many security issues have been addressed in the past.
>>
>> I told you in the last message: look at the Donwload page
>>
>>> Perhaps I am worrying about a case that never comes up.
>>> I have never seen an issue that was sufficiently important to trigger a release since I started following the project.
>>>>
>>>>>>
>>>>>>>
>>>>>>> This does not mean releasing things before they are ready.
>>>>>>> However once the team decides that a "release" is immutable, it is time to start the release process.
>>>>
>>>> Yes of course, that's how it's done. We don't publicize vulnerabilities before they are fixed in committed code
>>>>
>>>>>
>>>>>>> This may be a bit paradoxical - the closer to production - the less knowledgeable the talent required.
>>>>>>
>>>>>> I don't get it
>>>>> End-user's (system admins, business consultants) can create test scripts, document them, run them, create JIRA issues, try the installation of
>>>>> several operating systems, tweak the installation documentation, create test data.
>>>>>
>>>>> None of these activities require the skills needed to write new features, patch bugs.
>>>>
>>>> OK
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> It does reflect that facts that no architectural decisions are being made, few of the steps actually involve code modification and this can be
>>>>>>> done by the core committers.
>>>>>>
>>>>>> Still not
>>>>>>
>>>>>
>>>>> What is the problem with this statement?
>>>>> Is there some particular concern that I am not addressing?
>>>>
>>>> Actually it's more the goal you try to reach here I can't understand. Also the sentence
>>>> <<few of the steps actually involve code modification and this can be done by the core committers. >>
>>>> Seems contradictory to me
>>> I was trying to make the point that even if most of the work can be done by people who are not writing code, there may still be some bugs found
>>> that require code to fix and the code committers are still going to be available to do this.
>>> The goal is to free up the people committing code by having the rest of us take on some of the load involved in getting a release out.
>>>
>>>>
>>>>>
>>>>>>>
>>>>>>> A lot of the work is preparing release notes,
>>>>>>
>>>>>> We decided to let Jira does it, based on committers actions in Jira
>>>>>>
>>>>> Still needs to be edited for clarity , inconsistencies and missing items need to be detected and fixed.
>>>>>>> fixing documentation,
>>>>>>
>>>>>> Are we doing that rightly? I doubt
>>>>>
>>>>> The community can help if the PMC make the decision to work in a way that allows this to happen.
>>>>
>>>> Which decisions wouldyou suggest (apart splitting in sub-projects, we have all understand it's your pet subject ;) )?
>>>> We need to be more pragmatic here...
>>> 1) Decide to finish the release with the current set of issues (solved and outstanding)
>>> 2) Branch an RC.
>>> 3) List all of the tasks that need to be done and agree that completion of these tasks will result in a new release.
>>> 4) Create JIRAs against the tasks with the RC as the version including documentation, test configurations,
>>> 5) Solicit community involvement to accept assignment to JIRA issues
>>> 6) Fix JIRA items that require code changes
>>> 7) Vote out the release
>>>
>>>>
>>>>>
>>>>>>
>>>>>>> testing installation processes,
>>>>>>
>>>>>> Buildbot takes care of that
>>>>>
>>>>> I am not sure that this is true.
>>>>> You and I found errors in the Wiki the first time I tried to install and run OFBiz.
>>>>
>>>> You speak about "testing installation processes", this has nothing to do with the wiki. Builbot takes care of the tests for the trunk and the
>>>> living branches and a bit more (updates and upload Javadoc http://ci.apache.org/projects/ofbiz/site/javadocs/, creates Apache Rat reports
>>>> http://ci.apache.org/projects/ofbiz/rat-output.html, creates snapshots http://ci.apache.org/projects/ofbiz/snapshots/, copy test results
>>>> http://ci.apache.org/projects/ofbiz/logs/)
>>>>
>>>
>>> If the instructions in the wiki prevent the product from being deployed, that is an installation problem.
>>> So the person trying to use OFBiz, it does not matter why it does not work.
>>
>> Actually it's more simple than that. It's explained in the Download page and there is also a README in the "OFBiz root (folder)"
>> Maybe we should think otherwise and remove all things in the wiki which might not been ALWAYS maintained.
>> From this conversation I begin to wonder if it's not the right solution. Keep the documentation as simple as possible!
>>
>>>
>>>
>>>>>
>>>>> How many operating systems and database combinations are tested?
>>>>
>>>> Only Linux and Derby. It's a matter of resources.
>>>
>>> The community should be testing the combinations that they care about.
>>> It is their interest to be sure that the new release work for them.
>>
>> Agreed, not an OFBiz team issue
>>
>>>
>>>>
>>>>> What is the range of functionality tested?
>>>>
>>>> All tests present in OFBiz
>>>
>>> How is the GUI tested?
>>
>> That's missing. There was an effort, started by Erwan, but it was abandoned when he left the project.
>> https://issues.apache.org/jira/issues/?filter=12315391#
>>
>> I also tried to taker over another Erwan's effort, but had to give up for now: https://issues.apache.org/jira/browse/INFRA-3590
>>
>>> Are there written scripts describing each of the screens and combinations of data-entry values that are tested?
>>
>> Nope
>>
>>>
>>>
>>>>> How are the tests maintained.
>>>>
>>>> As well as possible
>>> Of course!
>>>>
>>>>> Is this something that the community could do?
>>>>
>>>> Yes the community could help. I'm not sure of the modality. I know for instance that the Neogia team is running their tests on Jenkins.
>>>
>>> I hope that this discussion is helping move this forward.
>>>
>>>>
>>>>>
>>>>>>
>>>>>>> updating seed data to demonstrate new features and testing under various scenarios.
>>>>>>
>>>>>> It's normally done correctly
>>>>>>
>>>>>
>>>>> I hope so but I notice that the Party demo data is pretty minimal and does not include basic elements such as Classifications or Postal Addresses.
>>>>> It has no customers or suppliers which would seem to be pretty important for testing an ERP.
>>>>
>>>> Then we (the community) should create Jira issues and if possible attach patches to those
>>>>
>>>
>>> Once I have the current ADTransform data loading scripts finished, I will be able to contribute a tool that will help by making it easier to add
>>> customers and employees with some of the standard supporting entities (postal addresses, e-mail, SIC Classification, telephone).
>>>
>>>>
>>>>>
>>>>>
>>>>>>> These are time-consuming and require different skills than adding features and fixing JIRA issues.
>>>>>>
>>>>>> Yes, but since it's done on a continuous-flow basis in Jira issues, we are better with that now
>>>>>
>>>>> I am not sure that it is done.
>>>>> We are spending a lot of time cleaning up bugs in the Wiki that date back several releases.
>>>>
>>>> Sorry, I don't consider that the wiki contains bugs, it only misses some love. BTW, thanks for your help there!
>>>>
>>>
>>> The Wiki is almost as important as the code to someone trying to adopt OFBiz.
>>> I hope that we can attract the same kind of community involvement in other areas of the project.
>>>
>>>>> The installation procedure documentation was not correct.
>>>>> I am not sure that data is added to the demo data to test/demonstrate each new function.
>>>>
>>>> It's still not always done when new features are added, and missing demo data from the past are not often considered.
>>>> But the situation is MUCH better than few years ago and it continues to improve (thanks Nicolas for your continued work on this!)
>>>>
>>>
>>> Great.
>>>
>>>>>
>>>>> It also takes too long since it is being done by people who are busy elsewhere.
>>>>> The current process also does not encourage the community to get involved.
>>>>
>>>> OK, would you not recommend to split the project in sub-projects?
>>>>
>>> I would but for other reasons.
>>>
>>> We can do this by providing a bit more leadership from the PMC and current committers.
>>> Sometimes you will be surprised by the response from people when you ask for help.
>>> By identifying specific tasks that need to be done and asking for volunteers, we might be surprised at the response.
>>
>> I have already been surprised few times. Problems: it does not always last...
>>
>>> By making it easy to work on an RC, the committers will have less work to do.
>>
>> In theory more work at start but less once done, in theory... Nothing prevents people to help, we are adults, aren't we?
>> That's how I started in 2005, I picked a subject (the POS then) and did my way from that.
>>
>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> If there are a lot of required issues, then make it a community project to release it and get it done.
>>>>>>>>>
>>>>>>>>> If it is not clear about the state of a release branch, then have a meeting and make a decision.
>>>>>>>>> Either it is
>>>>>>>>> a) still under development and unstable or
>>>>>>>>> b) it is a release candidate and only a defined and agreed upon set of bugs will be fixed before it is released and other low priority bugs
>>>>>>>>> and backports will get done in the next minor release. If a new critical bug is found after it is declared a RC, then the team gets to
>>>>>>>>> decide if it is included and adds it to the priority list or defers it.
>>>>>>>>> If it is deferred, add a note in the release notes that an important bug is not fixed in the release but is or will be available as a patch
>>>>>>>>> to the version in the trunk or development branch.
>>>>>>>>>
>>>>>>>>> This is not rocket science and if it done properly, in an organized way, it will be clear to Adrian and everyone how any backporting or bug
>>>>>>>>> fixing should be done.
>>>>>>>>
>>>>>>>> Wait, we have already a rule about that. Yours are maybe not rocket science but are too complicated IMO.
>>>>>>>>
>>>>>>>
>>>>>>> Do you have a link to the desription of the rule?
>>>>>>
>>>>>> No but you can create it in the wiki using what I wrote below
>>>>>
>>>>> I thought that you said that you had a rule?
>>>>
>>>> It was not written yet, but we could write it here https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
>>>>
>>>>> I am not sure that my release strategy would be described as a consensus view yet.;-)
>>>>
>>>> To clarify your view:
>>>> a) A release branch can't be in your situation a). No developments should occur in release branch, only bug fixes or trivial non functional
>>>> changes committed by consensus. Else it breaks the rule!
>>>> b) I agree about your point b)
>>>>
>>>>> I am certainly willing to help document this but I am certainly going push for something close to what I described above.
>>>>>
>>>>> What is the list of tasks that have to be done between a "freeze" and a "release".
>>>>
>>>> This indeed needs to be documented. But in a better manner than what we have achieved so far at
>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
>>>> Too much documentation kills the documentation (people use rather TL;DR)
>>>>
>>>>>
>>>>> Who manages this? How is the list developed? Who determines when enough testing has been done?
>>>>
>>>> It's not organised yet.
>>>>
>>>
>>> The question to the committers is"
>>> "Is it worthwhile taking the time to get organized so that others can help do the work."
>>
>> Sincerely... I have some doubts about that...
>>
>>>
>>>>>
>>>>> How is progress tracked? How is help from the community solicited during this phase.
>>>>
>>>> Not properly done yet.
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> How does Adrian's offer fit?
>>>>>>
>>>>>> I want to write more about that. Hopefully soon...
>>>>>>
>>>>>>>
>>>>>>>> There are 3 main types of changes:
>>>>>>>> 1) New features
>>>>>>>> 2) Improvements
>>>>>>>> 3) Bug fixes
>>>>>>>>
>>>>>>>> 3 should normally go in the release branches, as much as they can. Security fixes should trigger a new released packages.
>>>>>>>> 1 and 2 should never get into a release. Exceptions may occur, but they need a consensus, and as ever can be vetoed (only by committers,
>>>>>>>> though this rule can be adapted by the community: http://www.apache.org/foundation/voting.html#binding-votes)
>>>>>>>>
>>>>>>>>>
>>>>>>>>> "Sort of" stable branches is not really acceptable as a management policy for a production quality software product.
>>>>>>>>
>>>>>>>> I totally agree. I personally consider the trunk *bleeding edge*, a new "just frozen but not yet released branch" *edge* (it's still
>>>>>>>> stabilising, like R14.12 is today) and a "released branch" (like R13.07) *stable*.
>>>>>>>>
>>>>>>>
>>>>>>> Agreed.
>>>>>>>
>>>>>>> What is the current procedure for Adrian's offer to backport to 14.12. Does he have to start a 14.12.01 branch or can it be applied to 14.02?
>>>>>>
>>>>>> A 14.12.01 branch would be confusing (with the to come R14.12.01 Release which is unrelated). Another name could be used, we have never done
>>>>>> that and I'm against this idea
>>>>>>
>>>>> Agreed but without a policy that is agreed and followed, it makes these discussions difficult and sometime more heated than is good for the
>>>>> project.
>>>>> If 14.12.01 is coming out sometime in 2015 (no date) and he can't backport to the 4.12.01RC, he should start a 14.12.02 (sorry for my typo above
>>>>> which made things confusing).
>>>>
>>>> He can't backport if it's not bug fixes or trivial consensus changes .-
>>>>
>>>
>>> Should be documented as a policy so it does not become a clash of wills.
>>
>> This was clear so far. As I said we can write it, but it will not fundamentally change things, since we (committers) agreed on this already
>>
>>>
>>>>> However this now means that new patches need to be applied to the trunk, 14.12.01 (if they meet the unwritten criteria for inclusion in an
>>>>> immutable release) and 14.02.02 plus backported to earlier supported that need it.
>>>>
>>>> I'm against that
>>>>
>>>>>
>>>>>>> Who makes that decision? Is there already a policy that applies and does not need further discussion.
>>>>
>>>> Most of the time the community makes the decision by lazy consensus (the"famous" Apache way), but a PMC member can in all cases veto it.
>>>> http://apache.org/foundation/voting.html
>>>>
>>>
>>> Needs to be more transparent and set as policy to avoid conflicts whre policy is challenged in parallel with application of policy.
>>> Never completely avoidable but should be few and far between.
>>
>> I'm not against writing it, best place already suggested... Other opinions are welcome, if ever I missed something...
>>
>> Jacques
>>
>>>
>>>>
>>>>>>
>>>>>> No, we need to discuss about that
>>>>>>
>>>>>
>>>>> +1.
>>>>> I hope that this is helping a bit.
>>>>> I have changed the subject line since we have hijacked Adrian's topic.
>>>>
>>>> Yes, thanks!
>>>>
>>> Ron
>>>
>>>> Jacques
>>>>
>>>>>
>>>>>
>>>>> Ron
>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ron
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ron
>>>>>>>>>
>>>>>>>>> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>>>>>>>>>> I would though wait that all the possibly related opened Jiras will be fixed. Some projects are based on the R14.12 branch and people
>>>>>>>>>> expect this branch to be stable even if not yet released.
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>>>>>>>>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> After all of this work is completed, I would like to backport it to the R14 branch.
>>>>>>>>>>> Hi Adrian,
>>>>>>>>>>>
>>>>>>>>>>> I just wanted to mention that I agree that we should backport all this work to the 14.12 branch, which is pretty new and still needs to
>>>>>>>>>>> undergo to the stabilization process: in this way it will be easier to maintain it (by backporting the fixes) in the future years.
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: Release policy
Posted by Ron Wheeler <rw...@artifact-software.com>.
It is getting a bit long so I will make my comments at the top.
What is the plan for the next release?
Will it be 13.07.02 or 14.12.01?
Who is the project manager for the release project?
What has to be done to get it finalized?
What help is required? How do people sign up to help?
Is there going to be a meeting to kick off the process?
Ron
On 11/02/2015 5:23 PM, Jacques Le Roux wrote:
>
> Le 11/02/2015 21:14, Ron Wheeler a écrit :
>> On 11/02/2015 1:56 PM, Jacques Le Roux wrote:
>>>
>>> Le 09/02/2015 15:10, Ron Wheeler a écrit :
>>>> On 09/02/2015 5:21 AM, Jacques Le Roux wrote:
>>>>>
>>>>> Le 06/02/2015 17:27, Ron Wheeler a écrit :
>>>>>>
>>>>>> I would like to see more releases with smaller deltas so that the
>>>>>> trunk can be a bit more open to work where mistakes are not so
>>>>>> critical and cause so much grief since SI's will not feel that
>>>>>> they have to fork the trunk to get their customers a working
>>>>>> product.
>>>>>
>>>>> I believe people should rather user the last release branch than
>>>>> forking trunk or such
>>>>>
>>>>>> Security bugs need to be fixed, backported to all supported
>>>>>> versions and released before the exploit becomes public knowledge.
>>>>>>
>>>>>> This means that there must be an agile release process if you
>>>>>> want end-users to feel comfortable that their core data can be
>>>>>> secure while using OFBiz.
>>>>>
>>>>> What does mean "agile" here for you?
>>>> I do not have specific criteria in mind.
>>>> If the integrity of OFBiz data or business processes is at risk
>>>> from a security problem that has been raised in a JIRA, diagnosed,
>>>> fixed and advertised to the hacker community through the forum and
>>>> JIRA, it would be a good idea to issue a release and suggest that
>>>> people upgrade or issue an upgrade that can safely be applied by
>>>> end-users to their system ASAP.
>>>> Waiting for a year to issue a new release is not sufficiently agile
>>>> and I would expect a gradual improvement in the responsiveness over
>>>> time.
>>>> I am not sure how many security patches get issued each year and
>>>> how they are currently identified and tracked by the PMC.
>>>
>>> I thought you were not specifically speaking about security
>>> problems. Anyway, it's not done that way. Roughly: someone (a
>>> white-hat hacker) find an issue in OFBiz and report to the ASF
>>> security team http://www.apache.org/security/ (or rarely directly to
>>> the PMC, in private ML, so can't be read but by PMC members). The
>>> ASF security team then send the information to the PMC. The PMC
>>> fixes the issues ASAP. Then this issue is fixed in trunk and
>>> backported in all living branches in a shoot, a new release is
>>> created and a CVE https://cve.mitre.org/ created. Then the OFBiz
>>> Download page is updated
>> How many security issues have been addressed in the past.
>
> I told you in the last message: look at the Donwload page
>
>> Perhaps I am worrying about a case that never comes up.
>> I have never seen an issue that was sufficiently important to trigger
>> a release since I started following the project.
>>>
>>>>>
>>>>>>
>>>>>> This does not mean releasing things before they are ready.
>>>>>> However once the team decides that a "release" is immutable, it
>>>>>> is time to start the release process.
>>>
>>> Yes of course, that's how it's done. We don't publicize
>>> vulnerabilities before they are fixed in committed code
>>>
>>>>
>>>>>> This may be a bit paradoxical - the closer to production - the
>>>>>> less knowledgeable the talent required.
>>>>>
>>>>> I don't get it
>>>> End-user's (system admins, business consultants) can create test
>>>> scripts, document them, run them, create JIRA issues, try the
>>>> installation of several operating systems, tweak the installation
>>>> documentation, create test data.
>>>>
>>>> None of these activities require the skills needed to write new
>>>> features, patch bugs.
>>>
>>> OK
>>>
>>>>
>>>>>
>>>>>>
>>>>>> It does reflect that facts that no architectural decisions are
>>>>>> being made, few of the steps actually involve code modification
>>>>>> and this can be done by the core committers.
>>>>>
>>>>> Still not
>>>>>
>>>>
>>>> What is the problem with this statement?
>>>> Is there some particular concern that I am not addressing?
>>>
>>> Actually it's more the goal you try to reach here I can't
>>> understand. Also the sentence
>>> <<few of the steps actually involve code modification and this can
>>> be done by the core committers. >>
>>> Seems contradictory to me
>> I was trying to make the point that even if most of the work can be
>> done by people who are not writing code, there may still be some bugs
>> found that require code to fix and the code committers are still
>> going to be available to do this.
>> The goal is to free up the people committing code by having the rest
>> of us take on some of the load involved in getting a release out.
>>
>>>
>>>>
>>>>>>
>>>>>> A lot of the work is preparing release notes,
>>>>>
>>>>> We decided to let Jira does it, based on committers actions in Jira
>>>>>
>>>> Still needs to be edited for clarity , inconsistencies and missing
>>>> items need to be detected and fixed.
>>>>>> fixing documentation,
>>>>>
>>>>> Are we doing that rightly? I doubt
>>>>
>>>> The community can help if the PMC make the decision to work in a
>>>> way that allows this to happen.
>>>
>>> Which decisions wouldyou suggest (apart splitting in sub-projects,
>>> we have all understand it's your pet subject ;) )?
>>> We need to be more pragmatic here...
>> 1) Decide to finish the release with the current set of issues
>> (solved and outstanding)
>> 2) Branch an RC.
>> 3) List all of the tasks that need to be done and agree that
>> completion of these tasks will result in a new release.
>> 4) Create JIRAs against the tasks with the RC as the version
>> including documentation, test configurations,
>> 5) Solicit community involvement to accept assignment to JIRA issues
>> 6) Fix JIRA items that require code changes
>> 7) Vote out the release
>>
>>>
>>>>
>>>>>
>>>>>> testing installation processes,
>>>>>
>>>>> Buildbot takes care of that
>>>>
>>>> I am not sure that this is true.
>>>> You and I found errors in the Wiki the first time I tried to
>>>> install and run OFBiz.
>>>
>>> You speak about "testing installation processes", this has nothing
>>> to do with the wiki. Builbot takes care of the tests for the trunk
>>> and the living branches and a bit more (updates and upload Javadoc
>>> http://ci.apache.org/projects/ofbiz/site/javadocs/, creates Apache
>>> Rat reports http://ci.apache.org/projects/ofbiz/rat-output.html,
>>> creates snapshots http://ci.apache.org/projects/ofbiz/snapshots/,
>>> copy test results http://ci.apache.org/projects/ofbiz/logs/)
>>>
>>
>> If the instructions in the wiki prevent the product from being
>> deployed, that is an installation problem.
>> So the person trying to use OFBiz, it does not matter why it does not
>> work.
>
> Actually it's more simple than that. It's explained in the Download
> page and there is also a README in the "OFBiz root (folder)"
> Maybe we should think otherwise and remove all things in the wiki
> which might not been ALWAYS maintained.
> From this conversation I begin to wonder if it's not the right
> solution. Keep the documentation as simple as possible!
>
>>
>>
>>>>
>>>> How many operating systems and database combinations are tested?
>>>
>>> Only Linux and Derby. It's a matter of resources.
>>
>> The community should be testing the combinations that they care about.
>> It is their interest to be sure that the new release work for them.
>
> Agreed, not an OFBiz team issue
>
>>
>>>
>>>> What is the range of functionality tested?
>>>
>>> All tests present in OFBiz
>>
>> How is the GUI tested?
>
> That's missing. There was an effort, started by Erwan, but it was
> abandoned when he left the project.
> https://issues.apache.org/jira/issues/?filter=12315391#
>
> I also tried to taker over another Erwan's effort, but had to give up
> for now: https://issues.apache.org/jira/browse/INFRA-3590
>
>> Are there written scripts describing each of the screens and
>> combinations of data-entry values that are tested?
>
> Nope
>
>>
>>
>>>> How are the tests maintained.
>>>
>>> As well as possible
>> Of course!
>>>
>>>> Is this something that the community could do?
>>>
>>> Yes the community could help. I'm not sure of the modality. I know
>>> for instance that the Neogia team is running their tests on Jenkins.
>>
>> I hope that this discussion is helping move this forward.
>>
>>>
>>>>
>>>>>
>>>>>> updating seed data to demonstrate new features and testing under
>>>>>> various scenarios.
>>>>>
>>>>> It's normally done correctly
>>>>>
>>>>
>>>> I hope so but I notice that the Party demo data is pretty minimal
>>>> and does not include basic elements such as Classifications or
>>>> Postal Addresses.
>>>> It has no customers or suppliers which would seem to be pretty
>>>> important for testing an ERP.
>>>
>>> Then we (the community) should create Jira issues and if possible
>>> attach patches to those
>>>
>>
>> Once I have the current ADTransform data loading scripts finished, I
>> will be able to contribute a tool that will help by making it easier
>> to add customers and employees with some of the standard supporting
>> entities (postal addresses, e-mail, SIC Classification, telephone).
>>
>>>
>>>>
>>>>
>>>>>> These are time-consuming and require different skills than adding
>>>>>> features and fixing JIRA issues.
>>>>>
>>>>> Yes, but since it's done on a continuous-flow basis in Jira
>>>>> issues, we are better with that now
>>>>
>>>> I am not sure that it is done.
>>>> We are spending a lot of time cleaning up bugs in the Wiki that
>>>> date back several releases.
>>>
>>> Sorry, I don't consider that the wiki contains bugs, it only misses
>>> some love. BTW, thanks for your help there!
>>>
>>
>> The Wiki is almost as important as the code to someone trying to
>> adopt OFBiz.
>> I hope that we can attract the same kind of community involvement in
>> other areas of the project.
>>
>>>> The installation procedure documentation was not correct.
>>>> I am not sure that data is added to the demo data to
>>>> test/demonstrate each new function.
>>>
>>> It's still not always done when new features are added, and missing
>>> demo data from the past are not often considered.
>>> But the situation is MUCH better than few years ago and it continues
>>> to improve (thanks Nicolas for your continued work on this!)
>>>
>>
>> Great.
>>
>>>>
>>>> It also takes too long since it is being done by people who are
>>>> busy elsewhere.
>>>> The current process also does not encourage the community to get
>>>> involved.
>>>
>>> OK, would you not recommend to split the project in sub-projects?
>>>
>> I would but for other reasons.
>>
>> We can do this by providing a bit more leadership from the PMC and
>> current committers.
>> Sometimes you will be surprised by the response from people when you
>> ask for help.
>> By identifying specific tasks that need to be done and asking for
>> volunteers, we might be surprised at the response.
>
> I have already been surprised few times. Problems: it does not always
> last...
>
>> By making it easy to work on an RC, the committers will have less
>> work to do.
>
> In theory more work at start but less once done, in theory... Nothing
> prevents people to help, we are adults, aren't we?
> That's how I started in 2005, I picked a subject (the POS then) and
> did my way from that.
>
>
>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> If there are a lot of required issues, then make it a community
>>>>>>>> project to release it and get it done.
>>>>>>>>
>>>>>>>> If it is not clear about the state of a release branch, then
>>>>>>>> have a meeting and make a decision.
>>>>>>>> Either it is
>>>>>>>> a) still under development and unstable or
>>>>>>>> b) it is a release candidate and only a defined and agreed upon
>>>>>>>> set of bugs will be fixed before it is released and other low
>>>>>>>> priority bugs and backports will get done in the next minor
>>>>>>>> release. If a new critical bug is found after it is declared a
>>>>>>>> RC, then the team gets to decide if it is included and adds it
>>>>>>>> to the priority list or defers it.
>>>>>>>> If it is deferred, add a note in the release notes that an
>>>>>>>> important bug is not fixed in the release but is or will be
>>>>>>>> available as a patch to the version in the trunk or development
>>>>>>>> branch.
>>>>>>>>
>>>>>>>> This is not rocket science and if it done properly, in an
>>>>>>>> organized way, it will be clear to Adrian and everyone how any
>>>>>>>> backporting or bug fixing should be done.
>>>>>>>
>>>>>>> Wait, we have already a rule about that. Yours are maybe not
>>>>>>> rocket science but are too complicated IMO.
>>>>>>>
>>>>>>
>>>>>> Do you have a link to the desription of the rule?
>>>>>
>>>>> No but you can create it in the wiki using what I wrote below
>>>>
>>>> I thought that you said that you had a rule?
>>>
>>> It was not written yet, but we could write it here
>>> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
>>>
>>>> I am not sure that my release strategy would be described as a
>>>> consensus view yet.;-)
>>>
>>> To clarify your view:
>>> a) A release branch can't be in your situation a). No developments
>>> should occur in release branch, only bug fixes or trivial non
>>> functional changes committed by consensus. Else it breaks the rule!
>>> b) I agree about your point b)
>>>
>>>> I am certainly willing to help document this but I am certainly
>>>> going push for something close to what I described above.
>>>>
>>>> What is the list of tasks that have to be done between a "freeze"
>>>> and a "release".
>>>
>>> This indeed needs to be documented. But in a better manner than what
>>> we have achieved so far at
>>> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
>>> Too much documentation kills the documentation (people use rather
>>> TL;DR)
>>>
>>>>
>>>> Who manages this? How is the list developed? Who determines when
>>>> enough testing has been done?
>>>
>>> It's not organised yet.
>>>
>>
>> The question to the committers is"
>> "Is it worthwhile taking the time to get organized so that others can
>> help do the work."
>
> Sincerely... I have some doubts about that...
>
>>
>>>>
>>>> How is progress tracked? How is help from the community solicited
>>>> during this phase.
>>>
>>> Not properly done yet.
>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> How does Adrian's offer fit?
>>>>>
>>>>> I want to write more about that. Hopefully soon...
>>>>>
>>>>>>
>>>>>>> There are 3 main types of changes:
>>>>>>> 1) New features
>>>>>>> 2) Improvements
>>>>>>> 3) Bug fixes
>>>>>>>
>>>>>>> 3 should normally go in the release branches, as much as they
>>>>>>> can. Security fixes should trigger a new released packages.
>>>>>>> 1 and 2 should never get into a release. Exceptions may occur,
>>>>>>> but they need a consensus, and as ever can be vetoed (only by
>>>>>>> committers, though this rule can be adapted by the community:
>>>>>>> http://www.apache.org/foundation/voting.html#binding-votes)
>>>>>>>
>>>>>>>>
>>>>>>>> "Sort of" stable branches is not really acceptable as a
>>>>>>>> management policy for a production quality software product.
>>>>>>>
>>>>>>> I totally agree. I personally consider the trunk *bleeding
>>>>>>> edge*, a new "just frozen but not yet released branch" *edge*
>>>>>>> (it's still stabilising, like R14.12 is today) and a "released
>>>>>>> branch" (like R13.07) *stable*.
>>>>>>>
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>> What is the current procedure for Adrian's offer to backport to
>>>>>> 14.12. Does he have to start a 14.12.01 branch or can it be
>>>>>> applied to 14.02?
>>>>>
>>>>> A 14.12.01 branch would be confusing (with the to come R14.12.01
>>>>> Release which is unrelated). Another name could be used, we have
>>>>> never done that and I'm against this idea
>>>>>
>>>> Agreed but without a policy that is agreed and followed, it makes
>>>> these discussions difficult and sometime more heated than is good
>>>> for the project.
>>>> If 14.12.01 is coming out sometime in 2015 (no date) and he can't
>>>> backport to the 4.12.01RC, he should start a 14.12.02 (sorry for my
>>>> typo above which made things confusing).
>>>
>>> He can't backport if it's not bug fixes or trivial consensus changes .-
>>>
>>
>> Should be documented as a policy so it does not become a clash of wills.
>
> This was clear so far. As I said we can write it, but it will not
> fundamentally change things, since we (committers) agreed on this already
>
>>
>>>> However this now means that new patches need to be applied to the
>>>> trunk, 14.12.01 (if they meet the unwritten criteria for inclusion
>>>> in an immutable release) and 14.02.02 plus backported to earlier
>>>> supported that need it.
>>>
>>> I'm against that
>>>
>>>>
>>>>>> Who makes that decision? Is there already a policy that applies
>>>>>> and does not need further discussion.
>>>
>>> Most of the time the community makes the decision by lazy consensus
>>> (the"famous" Apache way), but a PMC member can in all cases veto it.
>>> http://apache.org/foundation/voting.html
>>>
>>
>> Needs to be more transparent and set as policy to avoid conflicts
>> whre policy is challenged in parallel with application of policy.
>> Never completely avoidable but should be few and far between.
>
> I'm not against writing it, best place already suggested... Other
> opinions are welcome, if ever I missed something...
>
> Jacques
>
>>
>>>
>>>>>
>>>>> No, we need to discuss about that
>>>>>
>>>>
>>>> +1.
>>>> I hope that this is helping a bit.
>>>> I have changed the subject line since we have hijacked Adrian's topic.
>>>
>>> Yes, thanks!
>>>
>> Ron
>>
>>> Jacques
>>>
>>>>
>>>>
>>>> Ron
>>>>
>>>>> Jacques
>>>>>
>>>>>>
>>>>>>
>>>>>> Ron
>>>>>>> Jacques
>>>>>>>
>>>>>>>>
>>>>>>>> Ron
>>>>>>>>
>>>>>>>> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>>>>>>>>> I would though wait that all the possibly related opened Jiras
>>>>>>>>> will be fixed. Some projects are based on the R14.12 branch
>>>>>>>>> and people expect this branch to be stable even if not yet
>>>>>>>>> released.
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>>>>>>>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum
>>>>>>>>>> <ad...@sandglass-software.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> After all of this work is completed, I would like to
>>>>>>>>>>> backport it to the R14 branch.
>>>>>>>>>> Hi Adrian,
>>>>>>>>>>
>>>>>>>>>> I just wanted to mention that I agree that we should backport
>>>>>>>>>> all this work to the 14.12 branch, which is pretty new and
>>>>>>>>>> still needs to undergo to the stabilization process: in this
>>>>>>>>>> way it will be easier to maintain it (by backporting the
>>>>>>>>>> fixes) in the future years.
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Release policy
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 11/02/2015 21:14, Ron Wheeler a écrit :
> On 11/02/2015 1:56 PM, Jacques Le Roux wrote:
>>
>> Le 09/02/2015 15:10, Ron Wheeler a écrit :
>>> On 09/02/2015 5:21 AM, Jacques Le Roux wrote:
>>>>
>>>> Le 06/02/2015 17:27, Ron Wheeler a écrit :
>>>>>
>>>>> I would like to see more releases with smaller deltas so that the trunk can be a bit more open to work where mistakes are not so critical and
>>>>> cause so much grief since SI's will not feel that they have to fork the trunk to get their customers a working product.
>>>>
>>>> I believe people should rather user the last release branch than forking trunk or such
>>>>
>>>>> Security bugs need to be fixed, backported to all supported versions and released before the exploit becomes public knowledge.
>>>>>
>>>>> This means that there must be an agile release process if you want end-users to feel comfortable that their core data can be secure while using
>>>>> OFBiz.
>>>>
>>>> What does mean "agile" here for you?
>>> I do not have specific criteria in mind.
>>> If the integrity of OFBiz data or business processes is at risk from a security problem that has been raised in a JIRA, diagnosed, fixed and
>>> advertised to the hacker community through the forum and JIRA, it would be a good idea to issue a release and suggest that people upgrade or
>>> issue an upgrade that can safely be applied by end-users to their system ASAP.
>>> Waiting for a year to issue a new release is not sufficiently agile and I would expect a gradual improvement in the responsiveness over time.
>>> I am not sure how many security patches get issued each year and how they are currently identified and tracked by the PMC.
>>
>> I thought you were not specifically speaking about security problems. Anyway, it's not done that way. Roughly: someone (a white-hat hacker) find an
>> issue in OFBiz and report to the ASF security team http://www.apache.org/security/ (or rarely directly to the PMC, in private ML, so can't be read
>> but by PMC members). The ASF security team then send the information to the PMC. The PMC fixes the issues ASAP. Then this issue is fixed in trunk
>> and backported in all living branches in a shoot, a new release is created and a CVE https://cve.mitre.org/ created. Then the OFBiz Download page
>> is updated
> How many security issues have been addressed in the past.
I told you in the last message: look at the Donwload page
> Perhaps I am worrying about a case that never comes up.
> I have never seen an issue that was sufficiently important to trigger a release since I started following the project.
>>
>>>>
>>>>>
>>>>> This does not mean releasing things before they are ready.
>>>>> However once the team decides that a "release" is immutable, it is time to start the release process.
>>
>> Yes of course, that's how it's done. We don't publicize vulnerabilities before they are fixed in committed code
>>
>>>
>>>>> This may be a bit paradoxical - the closer to production - the less knowledgeable the talent required.
>>>>
>>>> I don't get it
>>> End-user's (system admins, business consultants) can create test scripts, document them, run them, create JIRA issues, try the installation of
>>> several operating systems, tweak the installation documentation, create test data.
>>>
>>> None of these activities require the skills needed to write new features, patch bugs.
>>
>> OK
>>
>>>
>>>>
>>>>>
>>>>> It does reflect that facts that no architectural decisions are being made, few of the steps actually involve code modification and this can be
>>>>> done by the core committers.
>>>>
>>>> Still not
>>>>
>>>
>>> What is the problem with this statement?
>>> Is there some particular concern that I am not addressing?
>>
>> Actually it's more the goal you try to reach here I can't understand. Also the sentence
>> <<few of the steps actually involve code modification and this can be done by the core committers. >>
>> Seems contradictory to me
> I was trying to make the point that even if most of the work can be done by people who are not writing code, there may still be some bugs found that
> require code to fix and the code committers are still going to be available to do this.
> The goal is to free up the people committing code by having the rest of us take on some of the load involved in getting a release out.
>
>>
>>>
>>>>>
>>>>> A lot of the work is preparing release notes,
>>>>
>>>> We decided to let Jira does it, based on committers actions in Jira
>>>>
>>> Still needs to be edited for clarity , inconsistencies and missing items need to be detected and fixed.
>>>>> fixing documentation,
>>>>
>>>> Are we doing that rightly? I doubt
>>>
>>> The community can help if the PMC make the decision to work in a way that allows this to happen.
>>
>> Which decisions wouldyou suggest (apart splitting in sub-projects, we have all understand it's your pet subject ;) )?
>> We need to be more pragmatic here...
> 1) Decide to finish the release with the current set of issues (solved and outstanding)
> 2) Branch an RC.
> 3) List all of the tasks that need to be done and agree that completion of these tasks will result in a new release.
> 4) Create JIRAs against the tasks with the RC as the version including documentation, test configurations,
> 5) Solicit community involvement to accept assignment to JIRA issues
> 6) Fix JIRA items that require code changes
> 7) Vote out the release
>
>>
>>>
>>>>
>>>>> testing installation processes,
>>>>
>>>> Buildbot takes care of that
>>>
>>> I am not sure that this is true.
>>> You and I found errors in the Wiki the first time I tried to install and run OFBiz.
>>
>> You speak about "testing installation processes", this has nothing to do with the wiki. Builbot takes care of the tests for the trunk and the
>> living branches and a bit more (updates and upload Javadoc http://ci.apache.org/projects/ofbiz/site/javadocs/, creates Apache Rat reports
>> http://ci.apache.org/projects/ofbiz/rat-output.html, creates snapshots http://ci.apache.org/projects/ofbiz/snapshots/, copy test results
>> http://ci.apache.org/projects/ofbiz/logs/)
>>
>
> If the instructions in the wiki prevent the product from being deployed, that is an installation problem.
> So the person trying to use OFBiz, it does not matter why it does not work.
Actually it's more simple than that. It's explained in the Download page and there is also a README in the "OFBiz root (folder)"
Maybe we should think otherwise and remove all things in the wiki which might not been ALWAYS maintained.
From this conversation I begin to wonder if it's not the right solution. Keep the documentation as simple as possible!
>
>
>>>
>>> How many operating systems and database combinations are tested?
>>
>> Only Linux and Derby. It's a matter of resources.
>
> The community should be testing the combinations that they care about.
> It is their interest to be sure that the new release work for them.
Agreed, not an OFBiz team issue
>
>>
>>> What is the range of functionality tested?
>>
>> All tests present in OFBiz
>
> How is the GUI tested?
That's missing. There was an effort, started by Erwan, but it was abandoned when he left the project.
https://issues.apache.org/jira/issues/?filter=12315391#
I also tried to taker over another Erwan's effort, but had to give up for now: https://issues.apache.org/jira/browse/INFRA-3590
> Are there written scripts describing each of the screens and combinations of data-entry values that are tested?
Nope
>
>
>>> How are the tests maintained.
>>
>> As well as possible
> Of course!
>>
>>> Is this something that the community could do?
>>
>> Yes the community could help. I'm not sure of the modality. I know for instance that the Neogia team is running their tests on Jenkins.
>
> I hope that this discussion is helping move this forward.
>
>>
>>>
>>>>
>>>>> updating seed data to demonstrate new features and testing under various scenarios.
>>>>
>>>> It's normally done correctly
>>>>
>>>
>>> I hope so but I notice that the Party demo data is pretty minimal and does not include basic elements such as Classifications or Postal Addresses.
>>> It has no customers or suppliers which would seem to be pretty important for testing an ERP.
>>
>> Then we (the community) should create Jira issues and if possible attach patches to those
>>
>
> Once I have the current ADTransform data loading scripts finished, I will be able to contribute a tool that will help by making it easier to add
> customers and employees with some of the standard supporting entities (postal addresses, e-mail, SIC Classification, telephone).
>
>>
>>>
>>>
>>>>> These are time-consuming and require different skills than adding features and fixing JIRA issues.
>>>>
>>>> Yes, but since it's done on a continuous-flow basis in Jira issues, we are better with that now
>>>
>>> I am not sure that it is done.
>>> We are spending a lot of time cleaning up bugs in the Wiki that date back several releases.
>>
>> Sorry, I don't consider that the wiki contains bugs, it only misses some love. BTW, thanks for your help there!
>>
>
> The Wiki is almost as important as the code to someone trying to adopt OFBiz.
> I hope that we can attract the same kind of community involvement in other areas of the project.
>
>>> The installation procedure documentation was not correct.
>>> I am not sure that data is added to the demo data to test/demonstrate each new function.
>>
>> It's still not always done when new features are added, and missing demo data from the past are not often considered.
>> But the situation is MUCH better than few years ago and it continues to improve (thanks Nicolas for your continued work on this!)
>>
>
> Great.
>
>>>
>>> It also takes too long since it is being done by people who are busy elsewhere.
>>> The current process also does not encourage the community to get involved.
>>
>> OK, would you not recommend to split the project in sub-projects?
>>
> I would but for other reasons.
>
> We can do this by providing a bit more leadership from the PMC and current committers.
> Sometimes you will be surprised by the response from people when you ask for help.
> By identifying specific tasks that need to be done and asking for volunteers, we might be surprised at the response.
I have already been surprised few times. Problems: it does not always last...
> By making it easy to work on an RC, the committers will have less work to do.
In theory more work at start but less once done, in theory... Nothing prevents people to help, we are adults, aren't we?
That's how I started in 2005, I picked a subject (the POS then) and did my way from that.
>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>> If there are a lot of required issues, then make it a community project to release it and get it done.
>>>>>>>
>>>>>>> If it is not clear about the state of a release branch, then have a meeting and make a decision.
>>>>>>> Either it is
>>>>>>> a) still under development and unstable or
>>>>>>> b) it is a release candidate and only a defined and agreed upon set of bugs will be fixed before it is released and other low priority bugs
>>>>>>> and backports will get done in the next minor release. If a new critical bug is found after it is declared a RC, then the team gets to decide
>>>>>>> if it is included and adds it to the priority list or defers it.
>>>>>>> If it is deferred, add a note in the release notes that an important bug is not fixed in the release but is or will be available as a patch to
>>>>>>> the version in the trunk or development branch.
>>>>>>>
>>>>>>> This is not rocket science and if it done properly, in an organized way, it will be clear to Adrian and everyone how any backporting or bug
>>>>>>> fixing should be done.
>>>>>>
>>>>>> Wait, we have already a rule about that. Yours are maybe not rocket science but are too complicated IMO.
>>>>>>
>>>>>
>>>>> Do you have a link to the desription of the rule?
>>>>
>>>> No but you can create it in the wiki using what I wrote below
>>>
>>> I thought that you said that you had a rule?
>>
>> It was not written yet, but we could write it here https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
>>
>>> I am not sure that my release strategy would be described as a consensus view yet.;-)
>>
>> To clarify your view:
>> a) A release branch can't be in your situation a). No developments should occur in release branch, only bug fixes or trivial non functional changes
>> committed by consensus. Else it breaks the rule!
>> b) I agree about your point b)
>>
>>> I am certainly willing to help document this but I am certainly going push for something close to what I described above.
>>>
>>> What is the list of tasks that have to be done between a "freeze" and a "release".
>>
>> This indeed needs to be documented. But in a better manner than what we have achieved so far at
>> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
>> Too much documentation kills the documentation (people use rather TL;DR)
>>
>>>
>>> Who manages this? How is the list developed? Who determines when enough testing has been done?
>>
>> It's not organised yet.
>>
>
> The question to the committers is"
> "Is it worthwhile taking the time to get organized so that others can help do the work."
Sincerely... I have some doubts about that...
>
>>>
>>> How is progress tracked? How is help from the community solicited during this phase.
>>
>> Not properly done yet.
>>
>>>
>>>
>>>>
>>>>>
>>>>> How does Adrian's offer fit?
>>>>
>>>> I want to write more about that. Hopefully soon...
>>>>
>>>>>
>>>>>> There are 3 main types of changes:
>>>>>> 1) New features
>>>>>> 2) Improvements
>>>>>> 3) Bug fixes
>>>>>>
>>>>>> 3 should normally go in the release branches, as much as they can. Security fixes should trigger a new released packages.
>>>>>> 1 and 2 should never get into a release. Exceptions may occur, but they need a consensus, and as ever can be vetoed (only by committers, though
>>>>>> this rule can be adapted by the community: http://www.apache.org/foundation/voting.html#binding-votes)
>>>>>>
>>>>>>>
>>>>>>> "Sort of" stable branches is not really acceptable as a management policy for a production quality software product.
>>>>>>
>>>>>> I totally agree. I personally consider the trunk *bleeding edge*, a new "just frozen but not yet released branch" *edge* (it's still
>>>>>> stabilising, like R14.12 is today) and a "released branch" (like R13.07) *stable*.
>>>>>>
>>>>>
>>>>> Agreed.
>>>>>
>>>>> What is the current procedure for Adrian's offer to backport to 14.12. Does he have to start a 14.12.01 branch or can it be applied to 14.02?
>>>>
>>>> A 14.12.01 branch would be confusing (with the to come R14.12.01 Release which is unrelated). Another name could be used, we have never done that
>>>> and I'm against this idea
>>>>
>>> Agreed but without a policy that is agreed and followed, it makes these discussions difficult and sometime more heated than is good for the project.
>>> If 14.12.01 is coming out sometime in 2015 (no date) and he can't backport to the 4.12.01RC, he should start a 14.12.02 (sorry for my typo above
>>> which made things confusing).
>>
>> He can't backport if it's not bug fixes or trivial consensus changes .-
>>
>
> Should be documented as a policy so it does not become a clash of wills.
This was clear so far. As I said we can write it, but it will not fundamentally change things, since we (committers) agreed on this already
>
>>> However this now means that new patches need to be applied to the trunk, 14.12.01 (if they meet the unwritten criteria for inclusion in an
>>> immutable release) and 14.02.02 plus backported to earlier supported that need it.
>>
>> I'm against that
>>
>>>
>>>>> Who makes that decision? Is there already a policy that applies and does not need further discussion.
>>
>> Most of the time the community makes the decision by lazy consensus (the"famous" Apache way), but a PMC member can in all cases veto it.
>> http://apache.org/foundation/voting.html
>>
>
> Needs to be more transparent and set as policy to avoid conflicts whre policy is challenged in parallel with application of policy.
> Never completely avoidable but should be few and far between.
I'm not against writing it, best place already suggested... Other opinions are welcome, if ever I missed something...
Jacques
>
>>
>>>>
>>>> No, we need to discuss about that
>>>>
>>>
>>> +1.
>>> I hope that this is helping a bit.
>>> I have changed the subject line since we have hijacked Adrian's topic.
>>
>> Yes, thanks!
>>
> Ron
>
>> Jacques
>>
>>>
>>>
>>> Ron
>>>
>>>> Jacques
>>>>
>>>>>
>>>>>
>>>>> Ron
>>>>>> Jacques
>>>>>>
>>>>>>>
>>>>>>> Ron
>>>>>>>
>>>>>>> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>>>>>>>> I would though wait that all the possibly related opened Jiras will be fixed. Some projects are based on the R14.12 branch and people expect
>>>>>>>> this branch to be stable even if not yet released.
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>>>>>>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>>>>>>>>>
>>>>>>>>>> After all of this work is completed, I would like to backport it to the R14 branch.
>>>>>>>>> Hi Adrian,
>>>>>>>>>
>>>>>>>>> I just wanted to mention that I agree that we should backport all this work to the 14.12 branch, which is pretty new and still needs to
>>>>>>>>> undergo to the stabilization process: in this way it will be easier to maintain it (by backporting the fixes) in the future years.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: Release policy
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 11/02/2015 1:56 PM, Jacques Le Roux wrote:
>
> Le 09/02/2015 15:10, Ron Wheeler a écrit :
>> On 09/02/2015 5:21 AM, Jacques Le Roux wrote:
>>>
>>> Le 06/02/2015 17:27, Ron Wheeler a écrit :
>>>>
>>>> I would like to see more releases with smaller deltas so that the
>>>> trunk can be a bit more open to work where mistakes are not so
>>>> critical and cause so much grief since SI's will not feel that they
>>>> have to fork the trunk to get their customers a working product.
>>>
>>> I believe people should rather user the last release branch than
>>> forking trunk or such
>>>
>>>> Security bugs need to be fixed, backported to all supported
>>>> versions and released before the exploit becomes public knowledge.
>>>>
>>>> This means that there must be an agile release process if you want
>>>> end-users to feel comfortable that their core data can be secure
>>>> while using OFBiz.
>>>
>>> What does mean "agile" here for you?
>> I do not have specific criteria in mind.
>> If the integrity of OFBiz data or business processes is at risk from
>> a security problem that has been raised in a JIRA, diagnosed, fixed
>> and advertised to the hacker community through the forum and JIRA,
>> it would be a good idea to issue a release and suggest that people
>> upgrade or issue an upgrade that can safely be applied by end-users
>> to their system ASAP.
>> Waiting for a year to issue a new release is not sufficiently agile
>> and I would expect a gradual improvement in the responsiveness over
>> time.
>> I am not sure how many security patches get issued each year and how
>> they are currently identified and tracked by the PMC.
>
> I thought you were not specifically speaking about security problems.
> Anyway, it's not done that way. Roughly: someone (a white-hat hacker)
> find an issue in OFBiz and report to the ASF security team
> http://www.apache.org/security/ (or rarely directly to the PMC, in
> private ML, so can't be read but by PMC members). The ASF security
> team then send the information to the PMC. The PMC fixes the issues
> ASAP. Then this issue is fixed in trunk and backported in all living
> branches in a shoot, a new release is created and a CVE
> https://cve.mitre.org/ created. Then the OFBiz Download page is updated
How many security issues have been addressed in the past.
Perhaps I am worrying about a case that never comes up.
I have never seen an issue that was sufficiently important to trigger a
release since I started following the project.
>
>>>
>>>>
>>>> This does not mean releasing things before they are ready.
>>>> However once the team decides that a "release" is immutable, it is
>>>> time to start the release process.
>
> Yes of course, that's how it's done. We don't publicize
> vulnerabilities before they are fixed in committed code
>
>>
>>>> This may be a bit paradoxical - the closer to production - the less
>>>> knowledgeable the talent required.
>>>
>>> I don't get it
>> End-user's (system admins, business consultants) can create test
>> scripts, document them, run them, create JIRA issues, try the
>> installation of several operating systems, tweak the installation
>> documentation, create test data.
>>
>> None of these activities require the skills needed to write new
>> features, patch bugs.
>
> OK
>
>>
>>>
>>>>
>>>> It does reflect that facts that no architectural decisions are
>>>> being made, few of the steps actually involve code modification and
>>>> this can be done by the core committers.
>>>
>>> Still not
>>>
>>
>> What is the problem with this statement?
>> Is there some particular concern that I am not addressing?
>
> Actually it's more the goal you try to reach here I can't understand.
> Also the sentence
> <<few of the steps actually involve code modification and this can be
> done by the core committers. >>
> Seems contradictory to me
I was trying to make the point that even if most of the work can be done
by people who are not writing code, there may still be some bugs found
that require code to fix and the code committers are still going to be
available to do this.
The goal is to free up the people committing code by having the rest of
us take on some of the load involved in getting a release out.
>
>>
>>>>
>>>> A lot of the work is preparing release notes,
>>>
>>> We decided to let Jira does it, based on committers actions in Jira
>>>
>> Still needs to be edited for clarity , inconsistencies and missing
>> items need to be detected and fixed.
>>>> fixing documentation,
>>>
>>> Are we doing that rightly? I doubt
>>
>> The community can help if the PMC make the decision to work in a way
>> that allows this to happen.
>
> Which decisions wouldyou suggest (apart splitting in sub-projects, we
> have all understand it's your pet subject ;) )?
> We need to be more pragmatic here...
1) Decide to finish the release with the current set of issues (solved
and outstanding)
2) Branch an RC.
3) List all of the tasks that need to be done and agree that completion
of these tasks will result in a new release.
4) Create JIRAs against the tasks with the RC as the version including
documentation, test configurations,
5) Solicit community involvement to accept assignment to JIRA issues
6) Fix JIRA items that require code changes
7) Vote out the release
>
>>
>>>
>>>> testing installation processes,
>>>
>>> Buildbot takes care of that
>>
>> I am not sure that this is true.
>> You and I found errors in the Wiki the first time I tried to install
>> and run OFBiz.
>
> You speak about "testing installation processes", this has nothing to
> do with the wiki. Builbot takes care of the tests for the trunk and
> the living branches and a bit more (updates and upload Javadoc
> http://ci.apache.org/projects/ofbiz/site/javadocs/, creates Apache Rat
> reports http://ci.apache.org/projects/ofbiz/rat-output.html, creates
> snapshots http://ci.apache.org/projects/ofbiz/snapshots/, copy test
> results http://ci.apache.org/projects/ofbiz/logs/)
>
If the instructions in the wiki prevent the product from being deployed,
that is an installation problem.
So the person trying to use OFBiz, it does not matter why it does not work.
>>
>> How many operating systems and database combinations are tested?
>
> Only Linux and Derby. It's a matter of resources.
The community should be testing the combinations that they care about.
It is their interest to be sure that the new release work for them.
>
>> What is the range of functionality tested?
>
> All tests present in OFBiz
How is the GUI tested?
Are there written scripts describing each of the screens and
combinations of data-entry values that are tested?
>> How are the tests maintained.
>
> As well as possible
Of course!
>
>> Is this something that the community could do?
>
> Yes the community could help. I'm not sure of the modality. I know for
> instance that the Neogia team is running their tests on Jenkins.
I hope that this discussion is helping move this forward.
>
>>
>>>
>>>> updating seed data to demonstrate new features and testing under
>>>> various scenarios.
>>>
>>> It's normally done correctly
>>>
>>
>> I hope so but I notice that the Party demo data is pretty minimal and
>> does not include basic elements such as Classifications or Postal
>> Addresses.
>> It has no customers or suppliers which would seem to be pretty
>> important for testing an ERP.
>
> Then we (the community) should create Jira issues and if possible
> attach patches to those
>
Once I have the current ADTransform data loading scripts finished, I
will be able to contribute a tool that will help by making it easier to
add customers and employees with some of the standard supporting
entities (postal addresses, e-mail, SIC Classification, telephone).
>
>>
>>
>>>> These are time-consuming and require different skills than adding
>>>> features and fixing JIRA issues.
>>>
>>> Yes, but since it's done on a continuous-flow basis in Jira issues,
>>> we are better with that now
>>
>> I am not sure that it is done.
>> We are spending a lot of time cleaning up bugs in the Wiki that date
>> back several releases.
>
> Sorry, I don't consider that the wiki contains bugs, it only misses
> some love. BTW, thanks for your help there!
>
The Wiki is almost as important as the code to someone trying to adopt
OFBiz.
I hope that we can attract the same kind of community involvement in
other areas of the project.
>> The installation procedure documentation was not correct.
>> I am not sure that data is added to the demo data to test/demonstrate
>> each new function.
>
> It's still not always done when new features are added, and missing
> demo data from the past are not often considered.
> But the situation is MUCH better than few years ago and it continues
> to improve (thanks Nicolas for your continued work on this!)
>
Great.
>>
>> It also takes too long since it is being done by people who are busy
>> elsewhere.
>> The current process also does not encourage the community to get
>> involved.
>
> OK, would you not recommend to split the project in sub-projects?
>
I would but for other reasons.
We can do this by providing a bit more leadership from the PMC and
current committers.
Sometimes you will be surprised by the response from people when you ask
for help.
By identifying specific tasks that need to be done and asking for
volunteers, we might be surprised at the response.
By making it easy to work on an RC, the committers will have less work
to do.
>>
>>
>>
>>>
>>>>
>>>>>
>>>>>> If there are a lot of required issues, then make it a community
>>>>>> project to release it and get it done.
>>>>>>
>>>>>> If it is not clear about the state of a release branch, then have
>>>>>> a meeting and make a decision.
>>>>>> Either it is
>>>>>> a) still under development and unstable or
>>>>>> b) it is a release candidate and only a defined and agreed upon
>>>>>> set of bugs will be fixed before it is released and other low
>>>>>> priority bugs and backports will get done in the next minor
>>>>>> release. If a new critical bug is found after it is declared a
>>>>>> RC, then the team gets to decide if it is included and adds it to
>>>>>> the priority list or defers it.
>>>>>> If it is deferred, add a note in the release notes that an
>>>>>> important bug is not fixed in the release but is or will be
>>>>>> available as a patch to the version in the trunk or development
>>>>>> branch.
>>>>>>
>>>>>> This is not rocket science and if it done properly, in an
>>>>>> organized way, it will be clear to Adrian and everyone how any
>>>>>> backporting or bug fixing should be done.
>>>>>
>>>>> Wait, we have already a rule about that. Yours are maybe not
>>>>> rocket science but are too complicated IMO.
>>>>>
>>>>
>>>> Do you have a link to the desription of the rule?
>>>
>>> No but you can create it in the wiki using what I wrote below
>>
>> I thought that you said that you had a rule?
>
> It was not written yet, but we could write it here
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
>
>> I am not sure that my release strategy would be described as a
>> consensus view yet.;-)
>
> To clarify your view:
> a) A release branch can't be in your situation a). No developments
> should occur in release branch, only bug fixes or trivial non
> functional changes committed by consensus. Else it breaks the rule!
> b) I agree about your point b)
>
>> I am certainly willing to help document this but I am certainly going
>> push for something close to what I described above.
>>
>> What is the list of tasks that have to be done between a "freeze" and
>> a "release".
>
> This indeed needs to be documented. But in a better manner than what
> we have achieved so far at
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
> Too much documentation kills the documentation (people use rather TL;DR)
>
>>
>> Who manages this? How is the list developed? Who determines when
>> enough testing has been done?
>
> It's not organised yet.
>
The question to the committers is"
"Is it worthwhile taking the time to get organized so that others can
help do the work."
>>
>> How is progress tracked? How is help from the community solicited
>> during this phase.
>
> Not properly done yet.
>
>>
>>
>>>
>>>>
>>>> How does Adrian's offer fit?
>>>
>>> I want to write more about that. Hopefully soon...
>>>
>>>>
>>>>> There are 3 main types of changes:
>>>>> 1) New features
>>>>> 2) Improvements
>>>>> 3) Bug fixes
>>>>>
>>>>> 3 should normally go in the release branches, as much as they can.
>>>>> Security fixes should trigger a new released packages.
>>>>> 1 and 2 should never get into a release. Exceptions may occur, but
>>>>> they need a consensus, and as ever can be vetoed (only by
>>>>> committers, though this rule can be adapted by the community:
>>>>> http://www.apache.org/foundation/voting.html#binding-votes)
>>>>>
>>>>>>
>>>>>> "Sort of" stable branches is not really acceptable as a
>>>>>> management policy for a production quality software product.
>>>>>
>>>>> I totally agree. I personally consider the trunk *bleeding edge*,
>>>>> a new "just frozen but not yet released branch" *edge* (it's still
>>>>> stabilising, like R14.12 is today) and a "released branch" (like
>>>>> R13.07) *stable*.
>>>>>
>>>>
>>>> Agreed.
>>>>
>>>> What is the current procedure for Adrian's offer to backport to
>>>> 14.12. Does he have to start a 14.12.01 branch or can it be applied
>>>> to 14.02?
>>>
>>> A 14.12.01 branch would be confusing (with the to come R14.12.01
>>> Release which is unrelated). Another name could be used, we have
>>> never done that and I'm against this idea
>>>
>> Agreed but without a policy that is agreed and followed, it makes
>> these discussions difficult and sometime more heated than is good for
>> the project.
>> If 14.12.01 is coming out sometime in 2015 (no date) and he can't
>> backport to the 4.12.01RC, he should start a 14.12.02 (sorry for my
>> typo above which made things confusing).
>
> He can't backport if it's not bug fixes or trivial consensus changes .-
>
Should be documented as a policy so it does not become a clash of wills.
>> However this now means that new patches need to be applied to the
>> trunk, 14.12.01 (if they meet the unwritten criteria for inclusion in
>> an immutable release) and 14.02.02 plus backported to earlier
>> supported that need it.
>
> I'm against that
>
>>
>>>> Who makes that decision? Is there already a policy that applies and
>>>> does not need further discussion.
>
> Most of the time the community makes the decision by lazy consensus
> (the"famous" Apache way), but a PMC member can in all cases veto it.
> http://apache.org/foundation/voting.html
>
Needs to be more transparent and set as policy to avoid conflicts whre
policy is challenged in parallel with application of policy.
Never completely avoidable but should be few and far between.
>
>>>
>>> No, we need to discuss about that
>>>
>>
>> +1.
>> I hope that this is helping a bit.
>> I have changed the subject line since we have hijacked Adrian's topic.
>
> Yes, thanks!
>
Ron
> Jacques
>
>>
>>
>> Ron
>>
>>> Jacques
>>>
>>>>
>>>>
>>>> Ron
>>>>> Jacques
>>>>>
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>>>>>>> I would though wait that all the possibly related opened Jiras
>>>>>>> will be fixed. Some projects are based on the R14.12 branch and
>>>>>>> people expect this branch to be stable even if not yet released.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>>>>>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum
>>>>>>>> <ad...@sandglass-software.com> wrote:
>>>>>>>>
>>>>>>>>> After all of this work is completed, I would like to backport
>>>>>>>>> it to the R14 branch.
>>>>>>>> Hi Adrian,
>>>>>>>>
>>>>>>>> I just wanted to mention that I agree that we should backport
>>>>>>>> all this work to the 14.12 branch, which is pretty new and
>>>>>>>> still needs to undergo to the stabilization process: in this
>>>>>>>> way it will be easier to maintain it (by backporting the fixes)
>>>>>>>> in the future years.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Release policy
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 09/02/2015 15:10, Ron Wheeler a écrit :
> On 09/02/2015 5:21 AM, Jacques Le Roux wrote:
>>
>> Le 06/02/2015 17:27, Ron Wheeler a écrit :
>>>
>>> I would like to see more releases with smaller deltas so that the trunk can be a bit more open to work where mistakes are not so critical and
>>> cause so much grief since SI's will not feel that they have to fork the trunk to get their customers a working product.
>>
>> I believe people should rather user the last release branch than forking trunk or such
>>
>>> Security bugs need to be fixed, backported to all supported versions and released before the exploit becomes public knowledge.
>>>
>>> This means that there must be an agile release process if you want end-users to feel comfortable that their core data can be secure while using
>>> OFBiz.
>>
>> What does mean "agile" here for you?
> I do not have specific criteria in mind.
> If the integrity of OFBiz data or business processes is at risk from a security problem that has been raised in a JIRA, diagnosed, fixed and
> advertised to the hacker community through the forum and JIRA, it would be a good idea to issue a release and suggest that people upgrade or issue
> an upgrade that can safely be applied by end-users to their system ASAP.
> Waiting for a year to issue a new release is not sufficiently agile and I would expect a gradual improvement in the responsiveness over time.
> I am not sure how many security patches get issued each year and how they are currently identified and tracked by the PMC.
I thought you were not specifically speaking about security problems. Anyway, it's not done that way. Roughly: someone (a white-hat hacker) find an
issue in OFBiz and report to the ASF security team http://www.apache.org/security/ (or rarely directly to the PMC, in private ML, so can't be read but
by PMC members). The ASF security team then send the information to the PMC. The PMC fixes the issues ASAP. Then this issue is fixed in trunk and
backported in all living branches in a shoot, a new release is created and a CVE https://cve.mitre.org/ created. Then the OFBiz Download page is updated
>>
>>>
>>> This does not mean releasing things before they are ready.
>>> However once the team decides that a "release" is immutable, it is time to start the release process.
Yes of course, that's how it's done. We don't publicize vulnerabilities before they are fixed in committed code
>
>>> This may be a bit paradoxical - the closer to production - the less knowledgeable the talent required.
>>
>> I don't get it
> End-user's (system admins, business consultants) can create test scripts, document them, run them, create JIRA issues, try the installation of
> several operating systems, tweak the installation documentation, create test data.
>
> None of these activities require the skills needed to write new features, patch bugs.
OK
>
>>
>>>
>>> It does reflect that facts that no architectural decisions are being made, few of the steps actually involve code modification and this can be
>>> done by the core committers.
>>
>> Still not
>>
>
> What is the problem with this statement?
> Is there some particular concern that I am not addressing?
Actually it's more the goal you try to reach here I can't understand. Also the sentence
<<few of the steps actually involve code modification and this can be done by the core committers. >>
Seems contradictory to me
>
>>>
>>> A lot of the work is preparing release notes,
>>
>> We decided to let Jira does it, based on committers actions in Jira
>>
> Still needs to be edited for clarity , inconsistencies and missing items need to be detected and fixed.
>>> fixing documentation,
>>
>> Are we doing that rightly? I doubt
>
> The community can help if the PMC make the decision to work in a way that allows this to happen.
Which decisions wouldyou suggest (apart splitting in sub-projects, we have all understand it's your pet subject ;) )?
We need to be more pragmatic here...
>
>>
>>> testing installation processes,
>>
>> Buildbot takes care of that
>
> I am not sure that this is true.
> You and I found errors in the Wiki the first time I tried to install and run OFBiz.
You speak about "testing installation processes", this has nothing to do with the wiki. Builbot takes care of the tests for the trunk and the living
branches and a bit more (updates and upload Javadoc http://ci.apache.org/projects/ofbiz/site/javadocs/, creates Apache Rat reports
http://ci.apache.org/projects/ofbiz/rat-output.html, creates snapshots http://ci.apache.org/projects/ofbiz/snapshots/, copy test results
http://ci.apache.org/projects/ofbiz/logs/)
>
> How many operating systems and database combinations are tested?
Only Linux and Derby. It's a matter of resources.
> What is the range of functionality tested?
All tests present in OFBiz
> How are the tests maintained.
As well as possible
> Is this something that the community could do?
Yes the community could help. I'm not sure of the modality. I know for instance that the Neogia team is running their tests on Jenkins.
>
>>
>>> updating seed data to demonstrate new features and testing under various scenarios.
>>
>> It's normally done correctly
>>
>
> I hope so but I notice that the Party demo data is pretty minimal and does not include basic elements such as Classifications or Postal Addresses.
> It has no customers or suppliers which would seem to be pretty important for testing an ERP.
Then we (the community) should create Jira issues and if possible attach patches to those
>
>
>>> These are time-consuming and require different skills than adding features and fixing JIRA issues.
>>
>> Yes, but since it's done on a continuous-flow basis in Jira issues, we are better with that now
>
> I am not sure that it is done.
> We are spending a lot of time cleaning up bugs in the Wiki that date back several releases.
Sorry, I don't consider that the wiki contains bugs, it only misses some love. BTW, thanks for your help there!
> The installation procedure documentation was not correct.
> I am not sure that data is added to the demo data to test/demonstrate each new function.
It's still not always done when new features are added, and missing demo data from the past are not often considered.
But the situation is MUCH better than few years ago and it continues to improve (thanks Nicolas for your continued work on this!)
>
> It also takes too long since it is being done by people who are busy elsewhere.
> The current process also does not encourage the community to get involved.
OK, would you not recommend to split the project in sub-projects?
>
>
>
>>
>>>
>>>>
>>>>> If there are a lot of required issues, then make it a community project to release it and get it done.
>>>>>
>>>>> If it is not clear about the state of a release branch, then have a meeting and make a decision.
>>>>> Either it is
>>>>> a) still under development and unstable or
>>>>> b) it is a release candidate and only a defined and agreed upon set of bugs will be fixed before it is released and other low priority bugs and
>>>>> backports will get done in the next minor release. If a new critical bug is found after it is declared a RC, then the team gets to decide if it
>>>>> is included and adds it to the priority list or defers it.
>>>>> If it is deferred, add a note in the release notes that an important bug is not fixed in the release but is or will be available as a patch to
>>>>> the version in the trunk or development branch.
>>>>>
>>>>> This is not rocket science and if it done properly, in an organized way, it will be clear to Adrian and everyone how any backporting or bug
>>>>> fixing should be done.
>>>>
>>>> Wait, we have already a rule about that. Yours are maybe not rocket science but are too complicated IMO.
>>>>
>>>
>>> Do you have a link to the desription of the rule?
>>
>> No but you can create it in the wiki using what I wrote below
>
> I thought that you said that you had a rule?
It was not written yet, but we could write it here https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
> I am not sure that my release strategy would be described as a consensus view yet.;-)
To clarify your view:
a) A release branch can't be in your situation a). No developments should occur in release branch, only bug fixes or trivial non functional changes
committed by consensus. Else it breaks the rule!
b) I agree about your point b)
> I am certainly willing to help document this but I am certainly going push for something close to what I described above.
>
> What is the list of tasks that have to be done between a "freeze" and a "release".
This indeed needs to be documented. But in a better manner than what we have achieved so far at
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
Too much documentation kills the documentation (people use rather TL;DR)
>
> Who manages this? How is the list developed? Who determines when enough testing has been done?
It's not organised yet.
>
> How is progress tracked? How is help from the community solicited during this phase.
Not properly done yet.
>
>
>>
>>>
>>> How does Adrian's offer fit?
>>
>> I want to write more about that. Hopefully soon...
>>
>>>
>>>> There are 3 main types of changes:
>>>> 1) New features
>>>> 2) Improvements
>>>> 3) Bug fixes
>>>>
>>>> 3 should normally go in the release branches, as much as they can. Security fixes should trigger a new released packages.
>>>> 1 and 2 should never get into a release. Exceptions may occur, but they need a consensus, and as ever can be vetoed (only by committers, though
>>>> this rule can be adapted by the community: http://www.apache.org/foundation/voting.html#binding-votes)
>>>>
>>>>>
>>>>> "Sort of" stable branches is not really acceptable as a management policy for a production quality software product.
>>>>
>>>> I totally agree. I personally consider the trunk *bleeding edge*, a new "just frozen but not yet released branch" *edge* (it's still stabilising,
>>>> like R14.12 is today) and a "released branch" (like R13.07) *stable*.
>>>>
>>>
>>> Agreed.
>>>
>>> What is the current procedure for Adrian's offer to backport to 14.12. Does he have to start a 14.12.01 branch or can it be applied to 14.02?
>>
>> A 14.12.01 branch would be confusing (with the to come R14.12.01 Release which is unrelated). Another name could be used, we have never done that
>> and I'm against this idea
>>
> Agreed but without a policy that is agreed and followed, it makes these discussions difficult and sometime more heated than is good for the project.
> If 14.12.01 is coming out sometime in 2015 (no date) and he can't backport to the 4.12.01RC, he should start a 14.12.02 (sorry for my typo above
> which made things confusing).
He can't backport if it's not bug fixes or trivial consensus changes .-
> However this now means that new patches need to be applied to the trunk, 14.12.01 (if they meet the unwritten criteria for inclusion in an immutable
> release) and 14.02.02 plus backported to earlier supported that need it.
I'm against that
>
>>> Who makes that decision? Is there already a policy that applies and does not need further discussion.
Most of the time the community makes the decision by lazy consensus (the"famous" Apache way), but a PMC member can in all cases veto it.
http://apache.org/foundation/voting.html
>>
>> No, we need to discuss about that
>>
>
> +1.
> I hope that this is helping a bit.
> I have changed the subject line since we have hijacked Adrian's topic.
Yes, thanks!
Jacques
>
>
> Ron
>
>> Jacques
>>
>>>
>>>
>>> Ron
>>>> Jacques
>>>>
>>>>>
>>>>> Ron
>>>>>
>>>>> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>>>>>> I would though wait that all the possibly related opened Jiras will be fixed. Some projects are based on the R14.12 branch and people expect
>>>>>> this branch to be stable even if not yet released.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>>>>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>>>>>>>
>>>>>>>> After all of this work is completed, I would like to backport it to the R14 branch.
>>>>>>> Hi Adrian,
>>>>>>>
>>>>>>> I just wanted to mention that I agree that we should backport all this work to the 14.12 branch, which is pretty new and still needs to
>>>>>>> undergo to the stabilization process: in this way it will be easier to maintain it (by backporting the fixes) in the future years.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Release policy
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 09/02/2015 5:21 AM, Jacques Le Roux wrote:
>
> Le 06/02/2015 17:27, Ron Wheeler a écrit :
>> On 06/02/2015 10:02 AM, Jacques Le Roux wrote:
>>>
>>> Le 05/02/2015 15:41, Ron Wheeler a écrit :
>>>> Releases are stable.
>>>> Things that are not released are mutable.
>>>>
>>>> The use of unconventional conventions should be stopped as soon as
>>>> possible.
>>>
>>> +1! Thanks Ron, I'd hope that people express more their opinions
>>> before events happen than ranting after it's done, too late!
>>> I' also like to see us (committers) more as community servants than
>>> code owners. I must say, sometimes I also tend to believe it's my
>>> property, but it's not!
>>> The community gives us the power, not the code...
>>>
>>>>
>>>> If a branch has reached a state where no more changes except bug
>>>> fixes are expected then prioritize and clean up the JIRA issues
>>>> that are sufficiently important and likely to get fixed in the
>>>> short term and release it and start the development branch or trunk
>>>> on the way to the next minor release.
>>>
>>> I still prefer to give some time to time (It's said to be an Haitian
>>> proverb). It's not because we use to do that but because it's safer,
>>> and to be frank, also less work... In other words, I think our "one
>>> year before releasing" strategy is OK. Of course security issues are
>>> priority and accelerate the pace.
>>
>> I would like to see more releases with smaller deltas so that the
>> trunk can be a bit more open to work where mistakes are not so
>> critical and cause so much grief since SI's will not feel that they
>> have to fork the trunk to get their customers a working product.
>
> I believe people should rather user the last release branch than
> forking trunk or such
>
>> Security bugs need to be fixed, backported to all supported versions
>> and released before the exploit becomes public knowledge.
>>
>> This means that there must be an agile release process if you want
>> end-users to feel comfortable that their core data can be secure
>> while using OFBiz.
>
> What does mean "agile" here for you?
I do not have specific criteria in mind.
If the integrity of OFBiz data or business processes is at risk from a
security problem that has been raised in a JIRA, diagnosed, fixed and
advertised to the hacker community through the forum and JIRA, it would
be a good idea to issue a release and suggest that people upgrade or
issue an upgrade that can safely be applied by end-users to their system
ASAP.
Waiting for a year to issue a new release is not sufficiently agile and
I would expect a gradual improvement in the responsiveness over time.
I am not sure how many security patches get issued each year and how
they are currently identified and tracked by the PMC.
>
>>
>> This does not mean releasing things before they are ready.
>> However once the team decides that a "release" is immutable, it is
>> time to start the release process.
>
> As soon as we freeze a release branch it's normally immutable. It's
> though not yet ready to be released
>
What does immutable mean in this context? What is the process to go from
"immutable" to released?
>> This is perhaps the time for the community to get involved and more
>> committers allowed to help prepare the release.
>
> For now Jacopo prefer to do it himself. I'm not sure why. This should
> be rather documented...
>
>>
>> This may be a bit paradoxical - the closer to production - the less
>> knowledgeable the talent required.
>
> I don't get it
End-user's (system admins, business consultants) can create test
scripts, document them, run them, create JIRA issues, try the
installation of several operating systems, tweak the installation
documentation, create test data.
None of these activities require the skills needed to write new
features, patch bugs.
>
>>
>> It does reflect that facts that no architectural decisions are being
>> made, few of the steps actually involve code modification and this
>> can be done by the core committers.
>
> Still not
>
What is the problem with this statement?
Is there some particular concern that I am not addressing?
>>
>> A lot of the work is preparing release notes,
>
> We decided to let Jira does it, based on committers actions in Jira
>
Still needs to be edited for clarity , inconsistencies and missing items
need to be detected and fixed.
>> fixing documentation,
>
> Are we doing that rightly? I doubt
The community can help if the PMC make the decision to work in a way
that allows this to happen.
>
>> testing installation processes,
>
> Buildbot takes care of that
I am not sure that this is true.
You and I found errors in the Wiki the first time I tried to install and
run OFBiz.
How many operating systems and database combinations are tested?
What is the range of functionality tested?
How are the tests maintained.
Is this something that the community could do?
>
>> updating seed data to demonstrate new features and testing under
>> various scenarios.
>
> It's normally done correctly
>
I hope so but I notice that the Party demo data is pretty minimal and
does not include basic elements such as Classifications or Postal Addresses.
It has no customers or suppliers which would seem to be pretty important
for testing an ERP.
>> These are time-consuming and require different skills than adding
>> features and fixing JIRA issues.
>
> Yes, but since it's done on a continuous-flow basis in Jira issues, we
> are better with that now
I am not sure that it is done.
We are spending a lot of time cleaning up bugs in the Wiki that date
back several releases.
The installation procedure documentation was not correct.
I am not sure that data is added to the demo data to test/demonstrate
each new function.
It also takes too long since it is being done by people who are busy
elsewhere.
The current process also does not encourage the community to get involved.
>
>>
>>>
>>>> If there are a lot of required issues, then make it a community
>>>> project to release it and get it done.
>>>>
>>>> If it is not clear about the state of a release branch, then have a
>>>> meeting and make a decision.
>>>> Either it is
>>>> a) still under development and unstable or
>>>> b) it is a release candidate and only a defined and agreed upon set
>>>> of bugs will be fixed before it is released and other low priority
>>>> bugs and backports will get done in the next minor release. If a
>>>> new critical bug is found after it is declared a RC, then the team
>>>> gets to decide if it is included and adds it to the priority list
>>>> or defers it.
>>>> If it is deferred, add a note in the release notes that an
>>>> important bug is not fixed in the release but is or will be
>>>> available as a patch to the version in the trunk or development
>>>> branch.
>>>>
>>>> This is not rocket science and if it done properly, in an organized
>>>> way, it will be clear to Adrian and everyone how any backporting or
>>>> bug fixing should be done.
>>>
>>> Wait, we have already a rule about that. Yours are maybe not rocket
>>> science but are too complicated IMO.
>>>
>>
>> Do you have a link to the desription of the rule?
>
> No but you can create it in the wiki using what I wrote below
I thought that you said that you had a rule?
I am not sure that my release strategy would be described as a consensus
view yet.;-)
I am certainly willing to help document this but I am certainly going
push for something close to what I described above.
What is the list of tasks that have to be done between a "freeze" and a
"release".
Who manages this? How is the list developed? Who determines when enough
testing has been done?
How is progress tracked? How is help from the community solicited during
this phase.
>
>>
>> How does Adrian's offer fit?
>
> I want to write more about that. Hopefully soon...
>
>>
>>> There are 3 main types of changes:
>>> 1) New features
>>> 2) Improvements
>>> 3) Bug fixes
>>>
>>> 3 should normally go in the release branches, as much as they can.
>>> Security fixes should trigger a new released packages.
>>> 1 and 2 should never get into a release. Exceptions may occur, but
>>> they need a consensus, and as ever can be vetoed (only by
>>> committers, though this rule can be adapted by the community:
>>> http://www.apache.org/foundation/voting.html#binding-votes)
>>>
>>>>
>>>> "Sort of" stable branches is not really acceptable as a management
>>>> policy for a production quality software product.
>>>
>>> I totally agree. I personally consider the trunk *bleeding edge*, a
>>> new "just frozen but not yet released branch" *edge* (it's still
>>> stabilising, like R14.12 is today) and a "released branch" (like
>>> R13.07) *stable*.
>>>
>>
>> Agreed.
>>
>> What is the current procedure for Adrian's offer to backport to
>> 14.12. Does he have to start a 14.12.01 branch or can it be applied
>> to 14.02?
>
> A 14.12.01 branch would be confusing (with the to come R14.12.01
> Release which is unrelated). Another name could be used, we have never
> done that and I'm against this idea
>
Agreed but without a policy that is agreed and followed, it makes these
discussions difficult and sometime more heated than is good for the project.
If 14.12.01 is coming out sometime in 2015 (no date) and he can't
backport to the 4.12.01RC, he should start a 14.12.02 (sorry for my typo
above which made things confusing).
However this now means that new patches need to be applied to the trunk,
14.12.01 (if they meet the unwritten criteria for inclusion in an
immutable release) and 14.02.02 plus backported to earlier supported
that need it.
>> Who makes that decision? Is there already a policy that applies and
>> does not need further discussion.
>
> No, we need to discuss about that
>
+1.
I hope that this is helping a bit.
I have changed the subject line since we have hijacked Adrian's topic.
Ron
> Jacques
>
>>
>>
>> Ron
>>> Jacques
>>>
>>>>
>>>> Ron
>>>>
>>>> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>>>>> I would though wait that all the possibly related opened Jiras
>>>>> will be fixed. Some projects are based on the R14.12 branch and
>>>>> people expect this branch to be stable even if not yet released.
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>>>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum
>>>>>> <ad...@sandglass-software.com> wrote:
>>>>>>
>>>>>>> After all of this work is completed, I would like to backport it
>>>>>>> to the R14 branch.
>>>>>> Hi Adrian,
>>>>>>
>>>>>> I just wanted to mention that I agree that we should backport all
>>>>>> this work to the 14.12 branch, which is pretty new and still
>>>>>> needs to undergo to the stabilization process: in this way it
>>>>>> will be easier to maintain it (by backporting the fixes) in the
>>>>>> future years.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Widget Overhaul
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 09/02/2015 11:21, Jacques Le Roux a crit :
> Le 06/02/2015 17:27, Ron Wheeler a crit : If there are a lot of required issues, then make it a community project to release it and get it done.
>>>>
>>>> If it is not clear about the state of a release branch, then have a meeting and make a decision.
>>>> Either it is
>>>> a) still under development and unstable or
>>>> b) it is a release candidate and only a defined and agreed upon set of bugs will be fixed before it is released and other low priority bugs and
>>>> backports will get done in the next minor release. If a new critical bug is found after it is declared a RC, then the team gets to decide if it
>>>> is included and adds it to the priority list or defers it.
>>>> If it is deferred, add a note in the release notes that an important bug is not fixed in the release but is or will be available as a patch to
>>>> the version in the trunk or development branch.
>>>>
>>>> This is not rocket science and if it done properly, in an organized way, it will be clear to Adrian and everyone how any backporting or bug
>>>> fixing should be done.
>>>
>>> Wait, we have already a rule about that. Yours are maybe not rocket science but are too complicated IMO.
>>>
>>
>> Do you have a link to the desription of the rule?
>
> No but you can create it in the wiki using what I wrote below
Done
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=7766050&selectedPageVersions=42&selectedPageVersions=41
Jacques
Re: Widget Overhaul
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 06/02/2015 17:27, Ron Wheeler a écrit :
> On 06/02/2015 10:02 AM, Jacques Le Roux wrote:
>>
>> Le 05/02/2015 15:41, Ron Wheeler a écrit :
>>> Releases are stable.
>>> Things that are not released are mutable.
>>>
>>> The use of unconventional conventions should be stopped as soon as possible.
>>
>> +1! Thanks Ron, I'd hope that people express more their opinions before events happen than ranting after it's done, too late!
>> I' also like to see us (committers) more as community servants than code owners. I must say, sometimes I also tend to believe it's my property, but
>> it's not!
>> The community gives us the power, not the code...
>>
>>>
>>> If a branch has reached a state where no more changes except bug fixes are expected then prioritize and clean up the JIRA issues that are
>>> sufficiently important and likely to get fixed in the short term and release it and start the development branch or trunk on the way to the next
>>> minor release.
>>
>> I still prefer to give some time to time (It's said to be an Haitian proverb). It's not because we use to do that but because it's safer, and to be
>> frank, also less work... In other words, I think our "one year before releasing" strategy is OK. Of course security issues are priority and
>> accelerate the pace.
>
> I would like to see more releases with smaller deltas so that the trunk can be a bit more open to work where mistakes are not so critical and cause
> so much grief since SI's will not feel that they have to fork the trunk to get their customers a working product.
I believe people should rather user the last release branch than forking trunk or such
> Security bugs need to be fixed, backported to all supported versions and released before the exploit becomes public knowledge.
>
> This means that there must be an agile release process if you want end-users to feel comfortable that their core data can be secure while using OFBiz.
What does mean "agile" here for you?
>
> This does not mean releasing things before they are ready.
> However once the team decides that a "release" is immutable, it is time to start the release process.
As soon as we freeze a release branch it's normally immutable. It's though not yet ready to be released
> This is perhaps the time for the community to get involved and more committers allowed to help prepare the release.
For now Jacopo prefer to do it himself. I'm not sure why. This should be rather documented...
>
> This may be a bit paradoxical - the closer to production - the less knowledgeable the talent required.
I don't get it
>
> It does reflect that facts that no architectural decisions are being made, few of the steps actually involve code modification and this can be done
> by the core committers.
Still not
>
> A lot of the work is preparing release notes,
We decided to let Jira does it, based on committers actions in Jira
> fixing documentation,
Are we doing that rightly? I doubt
> testing installation processes,
Buildbot takes care of that
> updating seed data to demonstrate new features and testing under various scenarios.
It's normally done correctly
> These are time-consuming and require different skills than adding features and fixing JIRA issues.
Yes, but since it's done on a continuous-flow basis in Jira issues, we are better with that now
>
>>
>>> If there are a lot of required issues, then make it a community project to release it and get it done.
>>>
>>> If it is not clear about the state of a release branch, then have a meeting and make a decision.
>>> Either it is
>>> a) still under development and unstable or
>>> b) it is a release candidate and only a defined and agreed upon set of bugs will be fixed before it is released and other low priority bugs and
>>> backports will get done in the next minor release. If a new critical bug is found after it is declared a RC, then the team gets to decide if it is
>>> included and adds it to the priority list or defers it.
>>> If it is deferred, add a note in the release notes that an important bug is not fixed in the release but is or will be available as a patch to the
>>> version in the trunk or development branch.
>>>
>>> This is not rocket science and if it done properly, in an organized way, it will be clear to Adrian and everyone how any backporting or bug fixing
>>> should be done.
>>
>> Wait, we have already a rule about that. Yours are maybe not rocket science but are too complicated IMO.
>>
>
> Do you have a link to the desription of the rule?
No but you can create it in the wiki using what I wrote below
>
> How does Adrian's offer fit?
I want to write more about that. Hopefully soon...
>
>> There are 3 main types of changes:
>> 1) New features
>> 2) Improvements
>> 3) Bug fixes
>>
>> 3 should normally go in the release branches, as much as they can. Security fixes should trigger a new released packages.
>> 1 and 2 should never get into a release. Exceptions may occur, but they need a consensus, and as ever can be vetoed (only by committers, though
>> this rule can be adapted by the community: http://www.apache.org/foundation/voting.html#binding-votes)
>>
>>>
>>> "Sort of" stable branches is not really acceptable as a management policy for a production quality software product.
>>
>> I totally agree. I personally consider the trunk *bleeding edge*, a new "just frozen but not yet released branch" *edge* (it's still stabilising,
>> like R14.12 is today) and a "released branch" (like R13.07) *stable*.
>>
>
> Agreed.
>
> What is the current procedure for Adrian's offer to backport to 14.12. Does he have to start a 14.12.01 branch or can it be applied to 14.02?
A 14.12.01 branch would be confusing (with the to come R14.12.01 Release which is unrelated). Another name could be used, we have never done that and
I'm against this idea
> Who makes that decision? Is there already a policy that applies and does not need further discussion.
No, we need to discuss about that
Jacques
>
>
> Ron
>> Jacques
>>
>>>
>>> Ron
>>>
>>> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>>>> I would though wait that all the possibly related opened Jiras will be fixed. Some projects are based on the R14.12 branch and people expect this
>>>> branch to be stable even if not yet released.
>>>>
>>>> Jacques
>>>>
>>>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>>>>>
>>>>>> After all of this work is completed, I would like to backport it to the R14 branch.
>>>>> Hi Adrian,
>>>>>
>>>>> I just wanted to mention that I agree that we should backport all this work to the 14.12 branch, which is pretty new and still needs to undergo
>>>>> to the stabilization process: in this way it will be easier to maintain it (by backporting the fixes) in the future years.
>>>>>
>>>>> Jacopo
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Widget Overhaul
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 06/02/2015 10:02 AM, Jacques Le Roux wrote:
>
> Le 05/02/2015 15:41, Ron Wheeler a écrit :
>> Releases are stable.
>> Things that are not released are mutable.
>>
>> The use of unconventional conventions should be stopped as soon as
>> possible.
>
> +1! Thanks Ron, I'd hope that people express more their opinions
> before events happen than ranting after it's done, too late!
> I' also like to see us (committers) more as community servants than
> code owners. I must say, sometimes I also tend to believe it's my
> property, but it's not!
> The community gives us the power, not the code...
>
>>
>> If a branch has reached a state where no more changes except bug
>> fixes are expected then prioritize and clean up the JIRA issues that
>> are sufficiently important and likely to get fixed in the short term
>> and release it and start the development branch or trunk on the way
>> to the next minor release.
>
> I still prefer to give some time to time (It's said to be an Haitian
> proverb). It's not because we use to do that but because it's safer,
> and to be frank, also less work... In other words, I think our "one
> year before releasing" strategy is OK. Of course security issues are
> priority and accelerate the pace.
I would like to see more releases with smaller deltas so that the trunk
can be a bit more open to work where mistakes are not so critical and
cause so much grief since SI's will not feel that they have to fork the
trunk to get their customers a working product.
Security bugs need to be fixed, backported to all supported versions and
released before the exploit becomes public knowledge.
This means that there must be an agile release process if you want
end-users to feel comfortable that their core data can be secure while
using OFBiz.
This does not mean releasing things before they are ready.
However once the team decides that a "release" is immutable, it is time
to start the release process.
This is perhaps the time for the community to get involved and more
committers allowed to help prepare the release.
This may be a bit paradoxical - the closer to production - the less
knowledgeable the talent required.
It does reflect that facts that no architectural decisions are being
made, few of the steps actually involve code modification and this can
be done by the core committers.
A lot of the work is preparing release notes, fixing documentation,
testing installation processes, updating seed data to demonstrate new
features and testing under various scenarios.
These are time-consuming and require different skills than adding
features and fixing JIRA issues.
>
>> If there are a lot of required issues, then make it a community
>> project to release it and get it done.
>>
>> If it is not clear about the state of a release branch, then have a
>> meeting and make a decision.
>> Either it is
>> a) still under development and unstable or
>> b) it is a release candidate and only a defined and agreed upon set
>> of bugs will be fixed before it is released and other low priority
>> bugs and backports will get done in the next minor release. If a new
>> critical bug is found after it is declared a RC, then the team gets
>> to decide if it is included and adds it to the priority list or
>> defers it.
>> If it is deferred, add a note in the release notes that an important
>> bug is not fixed in the release but is or will be available as a
>> patch to the version in the trunk or development branch.
>>
>> This is not rocket science and if it done properly, in an organized
>> way, it will be clear to Adrian and everyone how any backporting or
>> bug fixing should be done.
>
> Wait, we have already a rule about that. Yours are maybe not rocket
> science but are too complicated IMO.
>
Do you have a link to the desription of the rule?
How does Adrian's offer fit?
> There are 3 main types of changes:
> 1) New features
> 2) Improvements
> 3) Bug fixes
>
> 3 should normally go in the release branches, as much as they can.
> Security fixes should trigger a new released packages.
> 1 and 2 should never get into a release. Exceptions may occur, but
> they need a consensus, and as ever can be vetoed (only by committers,
> though this rule can be adapted by the community:
> http://www.apache.org/foundation/voting.html#binding-votes)
>
>>
>> "Sort of" stable branches is not really acceptable as a management
>> policy for a production quality software product.
>
> I totally agree. I personally consider the trunk *bleeding edge*, a
> new "just frozen but not yet released branch" *edge* (it's still
> stabilising, like R14.12 is today) and a "released branch" (like
> R13.07) *stable*.
>
Agreed.
What is the current procedure for Adrian's offer to backport to 14.12.
Does he have to start a 14.12.01 branch or can it be applied to 14.02?
Who makes that decision? Is there already a policy that applies and does
not need further discussion.
Ron
> Jacques
>
>>
>> Ron
>>
>> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>>> I would though wait that all the possibly related opened Jiras will
>>> be fixed. Some projects are based on the R14.12 branch and people
>>> expect this branch to be stable even if not yet released.
>>>
>>> Jacques
>>>
>>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum
>>>> <ad...@sandglass-software.com> wrote:
>>>>
>>>>> After all of this work is completed, I would like to backport it
>>>>> to the R14 branch.
>>>> Hi Adrian,
>>>>
>>>> I just wanted to mention that I agree that we should backport all
>>>> this work to the 14.12 branch, which is pretty new and still needs
>>>> to undergo to the stabilization process: in this way it will be
>>>> easier to maintain it (by backporting the fixes) in the future years.
>>>>
>>>> Jacopo
>>>>
>>>
>>
>>
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Widget Overhaul
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 05/02/2015 15:41, Ron Wheeler a écrit :
> Releases are stable.
> Things that are not released are mutable.
>
> The use of unconventional conventions should be stopped as soon as possible.
+1! Thanks Ron, I'd hope that people express more their opinions before events happen than ranting after it's done, too late!
I' also like to see us (committers) more as community servants than code owners. I must say, sometimes I also tend to believe it's my property, but
it's not!
The community gives us the power, not the code...
>
> If a branch has reached a state where no more changes except bug fixes are expected then prioritize and clean up the JIRA issues that are
> sufficiently important and likely to get fixed in the short term and release it and start the development branch or trunk on the way to the next
> minor release.
I still prefer to give some time to time (It's said to be an Haitian proverb). It's not because we use to do that but because it's safer, and to be
frank, also less work... In other words, I think our "one year before releasing" strategy is OK. Of course security issues are priority and accelerate
the pace.
> If there are a lot of required issues, then make it a community project to release it and get it done.
>
> If it is not clear about the state of a release branch, then have a meeting and make a decision.
> Either it is
> a) still under development and unstable or
> b) it is a release candidate and only a defined and agreed upon set of bugs will be fixed before it is released and other low priority bugs and
> backports will get done in the next minor release. If a new critical bug is found after it is declared a RC, then the team gets to decide if it is
> included and adds it to the priority list or defers it.
> If it is deferred, add a note in the release notes that an important bug is not fixed in the release but is or will be available as a patch to the
> version in the trunk or development branch.
>
> This is not rocket science and if it done properly, in an organized way, it will be clear to Adrian and everyone how any backporting or bug fixing
> should be done.
Wait, we have already a rule about that. Yours are maybe not rocket science but are too complicated IMO.
There are 3 main types of changes:
1) New features
2) Improvements
3) Bug fixes
3 should normally go in the release branches, as much as they can. Security fixes should trigger a new released packages.
1 and 2 should never get into a release. Exceptions may occur, but they need a consensus, and as ever can be vetoed (only by committers, though this
rule can be adapted by the community: http://www.apache.org/foundation/voting.html#binding-votes)
>
> "Sort of" stable branches is not really acceptable as a management policy for a production quality software product.
I totally agree. I personally consider the trunk *bleeding edge*, a new "just frozen but not yet released branch" *edge* (it's still stabilising, like
R14.12 is today) and a "released branch" (like R13.07) *stable*.
Jacques
>
> Ron
>
> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>> I would though wait that all the possibly related opened Jiras will be fixed. Some projects are based on the R14.12 branch and people expect this
>> branch to be stable even if not yet released.
>>
>> Jacques
>>
>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>>>
>>>> After all of this work is completed, I would like to backport it to the R14 branch.
>>> Hi Adrian,
>>>
>>> I just wanted to mention that I agree that we should backport all this work to the 14.12 branch, which is pretty new and still needs to undergo to
>>> the stabilization process: in this way it will be easier to maintain it (by backporting the fixes) in the future years.
>>>
>>> Jacopo
>>>
>>
>
>
Re: Widget Overhaul
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 05/02/2015 9:49 AM, Adrian Crum wrote:
> All of this is already stated on the OFBiz web site, so I don't
> understand the point of this reply.
Reference?
>
> My plans are no different than many other branch backports that have
> been done in the past.
Jacques seemed to find that not to be true.
I thought that I was supporting your plan but you comment has me a bit
baffled.
Ron
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 2/5/2015 6:41 AM, Ron Wheeler wrote:
>> Releases are stable.
>> Things that are not released are mutable.
>>
>> The use of unconventional conventions should be stopped as soon as
>> possible.
>>
>> If a branch has reached a state where no more changes except bug fixes
>> are expected then prioritize and clean up the JIRA issues that are
>> sufficiently important and likely to get fixed in the short term and
>> release it and start the development branch or trunk on the way to the
>> next minor release.
>>
>> If there are a lot of required issues, then make it a community project
>> to release it and get it done.
>>
>> If it is not clear about the state of a release branch, then have a
>> meeting and make a decision.
>> Either it is
>> a) still under development and unstable or
>> b) it is a release candidate and only a defined and agreed upon set of
>> bugs will be fixed before it is released and other low priority bugs and
>> backports will get done in the next minor release. If a new critical bug
>> is found after it is declared a RC, then the team gets to decide if it
>> is included and adds it to the priority list or defers it.
>> If it is deferred, add a note in the release notes that an important bug
>> is not fixed in the release but is or will be available as a patch to
>> the version in the trunk or development branch.
>>
>> This is not rocket science and if it done properly, in an organized way,
>> it will be clear to Adrian and everyone how any backporting or bug
>> fixing should be done.
>>
>> "Sort of" stable branches is not really acceptable as a management
>> policy for a production quality software product.
>>
>> Ron
>>
>> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>>> I would though wait that all the possibly related opened Jiras will be
>>> fixed. Some projects are based on the R14.12 branch and people expect
>>> this branch to be stable even if not yet released.
>>>
>>> Jacques
>>>
>>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum
>>>> <ad...@sandglass-software.com> wrote:
>>>>
>>>>> After all of this work is completed, I would like to backport it to
>>>>> the R14 branch.
>>>> Hi Adrian,
>>>>
>>>> I just wanted to mention that I agree that we should backport all
>>>> this work to the 14.12 branch, which is pretty new and still needs to
>>>> undergo to the stabilization process: in this way it will be easier
>>>> to maintain it (by backporting the fixes) in the future years.
>>>>
>>>> Jacopo
>>>>
>>>
>>
>>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Widget Overhaul
Posted by Jacques Le Roux <ja...@les7arts.com>.
I created https://issues.apache.org/jira/browse/OFBIZ-6060 for that
While at it I found this discussion: http://markmail.org/message/e63blvefzkxvvjrn
I though noticed that nowadays clearing all caches manually does not take much time on an up to date machine. So clearing only services caches
(service.ModelServiceMapByModel and service.ServiceConfig) should no longer be a problem in dev mode and we could introduce a property for that in
cache.properties. What do you think?
Jacques
Le 05/02/2015 17:15, Jacques Le Roux a écrit :
> BTW I have just found something in trunk, but it's too early to speak about it. I will open "another" Jira when ready...
>
> Jacques
Re: Widget Overhaul
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 05/02/2015 15:49, Adrian Crum a écrit :
> All of this is already stated on the OFBiz web site, so I don't understand the point of this reply.
>
> My plans are no different than many other branch backports that have been done in the past.
If memory serves, other branches backports have always been done in trunk, not releases branches
Morevoer there have been some kirks recently related to these changes, that's why I'm cautious, it's not a simple thing.
BTW I have just found something in trunk, but it's too early to speak about it. I will open "another" Jira when ready...
Jacques
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 2/5/2015 6:41 AM, Ron Wheeler wrote:
>> Releases are stable.
>> Things that are not released are mutable.
>>
>> The use of unconventional conventions should be stopped as soon as
>> possible.
>>
>> If a branch has reached a state where no more changes except bug fixes
>> are expected then prioritize and clean up the JIRA issues that are
>> sufficiently important and likely to get fixed in the short term and
>> release it and start the development branch or trunk on the way to the
>> next minor release.
>>
>> If there are a lot of required issues, then make it a community project
>> to release it and get it done.
>>
>> If it is not clear about the state of a release branch, then have a
>> meeting and make a decision.
>> Either it is
>> a) still under development and unstable or
>> b) it is a release candidate and only a defined and agreed upon set of
>> bugs will be fixed before it is released and other low priority bugs and
>> backports will get done in the next minor release. If a new critical bug
>> is found after it is declared a RC, then the team gets to decide if it
>> is included and adds it to the priority list or defers it.
>> If it is deferred, add a note in the release notes that an important bug
>> is not fixed in the release but is or will be available as a patch to
>> the version in the trunk or development branch.
>>
>> This is not rocket science and if it done properly, in an organized way,
>> it will be clear to Adrian and everyone how any backporting or bug
>> fixing should be done.
>>
>> "Sort of" stable branches is not really acceptable as a management
>> policy for a production quality software product.
>>
>> Ron
>>
>> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>>> I would though wait that all the possibly related opened Jiras will be
>>> fixed. Some projects are based on the R14.12 branch and people expect
>>> this branch to be stable even if not yet released.
>>>
>>> Jacques
>>>
>>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum
>>>> <ad...@sandglass-software.com> wrote:
>>>>
>>>>> After all of this work is completed, I would like to backport it to
>>>>> the R14 branch.
>>>> Hi Adrian,
>>>>
>>>> I just wanted to mention that I agree that we should backport all
>>>> this work to the 14.12 branch, which is pretty new and still needs to
>>>> undergo to the stabilization process: in this way it will be easier
>>>> to maintain it (by backporting the fixes) in the future years.
>>>>
>>>> Jacopo
>>>>
>>>
>>
>>
>
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
All of this is already stated on the OFBiz web site, so I don't
understand the point of this reply.
My plans are no different than many other branch backports that have
been done in the past.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 2/5/2015 6:41 AM, Ron Wheeler wrote:
> Releases are stable.
> Things that are not released are mutable.
>
> The use of unconventional conventions should be stopped as soon as
> possible.
>
> If a branch has reached a state where no more changes except bug fixes
> are expected then prioritize and clean up the JIRA issues that are
> sufficiently important and likely to get fixed in the short term and
> release it and start the development branch or trunk on the way to the
> next minor release.
>
> If there are a lot of required issues, then make it a community project
> to release it and get it done.
>
> If it is not clear about the state of a release branch, then have a
> meeting and make a decision.
> Either it is
> a) still under development and unstable or
> b) it is a release candidate and only a defined and agreed upon set of
> bugs will be fixed before it is released and other low priority bugs and
> backports will get done in the next minor release. If a new critical bug
> is found after it is declared a RC, then the team gets to decide if it
> is included and adds it to the priority list or defers it.
> If it is deferred, add a note in the release notes that an important bug
> is not fixed in the release but is or will be available as a patch to
> the version in the trunk or development branch.
>
> This is not rocket science and if it done properly, in an organized way,
> it will be clear to Adrian and everyone how any backporting or bug
> fixing should be done.
>
> "Sort of" stable branches is not really acceptable as a management
> policy for a production quality software product.
>
> Ron
>
> On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
>> I would though wait that all the possibly related opened Jiras will be
>> fixed. Some projects are based on the R14.12 branch and people expect
>> this branch to be stable even if not yet released.
>>
>> Jacques
>>
>> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>>> On Jan 17, 2015, at 11:16 PM, Adrian Crum
>>> <ad...@sandglass-software.com> wrote:
>>>
>>>> After all of this work is completed, I would like to backport it to
>>>> the R14 branch.
>>> Hi Adrian,
>>>
>>> I just wanted to mention that I agree that we should backport all
>>> this work to the 14.12 branch, which is pretty new and still needs to
>>> undergo to the stabilization process: in this way it will be easier
>>> to maintain it (by backporting the fixes) in the future years.
>>>
>>> Jacopo
>>>
>>
>
>
Re: Widget Overhaul
Posted by Ron Wheeler <rw...@artifact-software.com>.
Releases are stable.
Things that are not released are mutable.
The use of unconventional conventions should be stopped as soon as possible.
If a branch has reached a state where no more changes except bug fixes
are expected then prioritize and clean up the JIRA issues that are
sufficiently important and likely to get fixed in the short term and
release it and start the development branch or trunk on the way to the
next minor release.
If there are a lot of required issues, then make it a community project
to release it and get it done.
If it is not clear about the state of a release branch, then have a
meeting and make a decision.
Either it is
a) still under development and unstable or
b) it is a release candidate and only a defined and agreed upon set of
bugs will be fixed before it is released and other low priority bugs and
backports will get done in the next minor release. If a new critical bug
is found after it is declared a RC, then the team gets to decide if it
is included and adds it to the priority list or defers it.
If it is deferred, add a note in the release notes that an important bug
is not fixed in the release but is or will be available as a patch to
the version in the trunk or development branch.
This is not rocket science and if it done properly, in an organized way,
it will be clear to Adrian and everyone how any backporting or bug
fixing should be done.
"Sort of" stable branches is not really acceptable as a management
policy for a production quality software product.
Ron
On 05/02/2015 3:26 AM, Jacques Le Roux wrote:
> I would though wait that all the possibly related opened Jiras will be
> fixed. Some projects are based on the R14.12 branch and people expect
> this branch to be stable even if not yet released.
>
> Jacques
>
> Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
>> On Jan 17, 2015, at 11:16 PM, Adrian Crum
>> <ad...@sandglass-software.com> wrote:
>>
>>> After all of this work is completed, I would like to backport it to
>>> the R14 branch.
>> Hi Adrian,
>>
>> I just wanted to mention that I agree that we should backport all
>> this work to the 14.12 branch, which is pretty new and still needs to
>> undergo to the stabilization process: in this way it will be easier
>> to maintain it (by backporting the fixes) in the future years.
>>
>> Jacopo
>>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Widget Overhaul
Posted by Jacques Le Roux <ja...@les7arts.com>.
I would though wait that all the possibly related opened Jiras will be fixed. Some projects are based on the R14.12 branch and people expect this
branch to be stable even if not yet released.
Jacques
Le 04/02/2015 06:34, Jacopo Cappellato a écrit :
> On Jan 17, 2015, at 11:16 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>
>> After all of this work is completed, I would like to backport it to the R14 branch.
> Hi Adrian,
>
> I just wanted to mention that I agree that we should backport all this work to the 14.12 branch, which is pretty new and still needs to undergo to the stabilization process: in this way it will be easier to maintain it (by backporting the fixes) in the future years.
>
> Jacopo
>
Re: Widget Overhaul
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Jan 17, 2015, at 11:16 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
> After all of this work is completed, I would like to backport it to the R14 branch.
Hi Adrian,
I just wanted to mention that I agree that we should backport all this work to the 14.12 branch, which is pretty new and still needs to undergo to the stabilization process: in this way it will be easier to maintain it (by backporting the fixes) in the future years.
Jacopo
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
I am not doing anything that affects performance, so I am not interested
in a comparison.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 2:58 PM, Pierre Smits wrote:
> True.
>
> But would you not like it that this refactoring isn't a factor when a
> comparison between a release and trunk shows that trunk is performing worse
> than a release?
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sat, Jan 17, 2015 at 10:44 PM, Adrian Crum <
> adrian.crum@sandglass-software.com> wrote:
>
>> Comparisons can be done on any branch.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/17/2015 1:40 PM, Pierre Smits wrote:
>>
>>> Hi Adrian,
>>>
>>> I am inclined to say that any code improvement that removes quirkiness in
>>> current code or unpredictable behaviour while at the same time helping
>>> contributors to develop better solutions deserves a +1.
>>>
>>> However I have some concerns regarding the approach you're following.
>>>
>>> First, as we can expect that the quirkiness in current widget code is
>>> being
>>> utilized in various places in the dependent components, refactoring the
>>> widget code can lead to a multitude of issues regarding Screens and Forms
>>> in those components. I truly hope this will be as bad as I fear.
>>>
>>> Secondly, refactoring the widget code will have an impact on performance.
>>> I
>>> am sure we all hope (and some will expect it to be so) it is a positive
>>> effect, but we can't tell - at this moment in time - what it will be.
>>>
>>> Given the two concerns I would rather have seen that the refactoring was
>>> taking place in a separate development branch than in trunk. Having it
>>> done
>>> that way we would have the opportunity to compare the performance aspects
>>> of the refactored code against trunk (e.g. with Apache jMeter and such),
>>> and if favourable have another argument to tell to the users of old
>>> releases.
>>>
>>> Also while having the refactoring taking place in the development branch,
>>> we can not only isolate the aspects of my first concern (development
>>> branch
>>> issues vs trunk issues), but we will be able to better explain what the
>>> effects of the refactoring could be visavis (potential) issues of the
>>> users
>>> of old versions considering upgrading.
>>>
>>> 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 Sat, Jan 17, 2015 at 6:46 PM, Adrian Crum <
>>> adrian.crum@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
>>>>
>>>>
>>>
>
Re: Widget Overhaul
Posted by Pierre Smits <pi...@gmail.com>.
True.
But would you not like it that this refactoring isn't a factor when a
comparison between a release and trunk shows that trunk is performing worse
than a release?
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Sat, Jan 17, 2015 at 10:44 PM, Adrian Crum <
adrian.crum@sandglass-software.com> wrote:
> Comparisons can be done on any branch.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/17/2015 1:40 PM, Pierre Smits wrote:
>
>> Hi Adrian,
>>
>> I am inclined to say that any code improvement that removes quirkiness in
>> current code or unpredictable behaviour while at the same time helping
>> contributors to develop better solutions deserves a +1.
>>
>> However I have some concerns regarding the approach you're following.
>>
>> First, as we can expect that the quirkiness in current widget code is
>> being
>> utilized in various places in the dependent components, refactoring the
>> widget code can lead to a multitude of issues regarding Screens and Forms
>> in those components. I truly hope this will be as bad as I fear.
>>
>> Secondly, refactoring the widget code will have an impact on performance.
>> I
>> am sure we all hope (and some will expect it to be so) it is a positive
>> effect, but we can't tell - at this moment in time - what it will be.
>>
>> Given the two concerns I would rather have seen that the refactoring was
>> taking place in a separate development branch than in trunk. Having it
>> done
>> that way we would have the opportunity to compare the performance aspects
>> of the refactored code against trunk (e.g. with Apache jMeter and such),
>> and if favourable have another argument to tell to the users of old
>> releases.
>>
>> Also while having the refactoring taking place in the development branch,
>> we can not only isolate the aspects of my first concern (development
>> branch
>> issues vs trunk issues), but we will be able to better explain what the
>> effects of the refactoring could be visavis (potential) issues of the
>> users
>> of old versions considering upgrading.
>>
>> 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 Sat, Jan 17, 2015 at 6:46 PM, Adrian Crum <
>> adrian.crum@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
>>>
>>>
>>
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
Comparisons can be done on any branch.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 1:40 PM, Pierre Smits wrote:
> Hi Adrian,
>
> I am inclined to say that any code improvement that removes quirkiness in
> current code or unpredictable behaviour while at the same time helping
> contributors to develop better solutions deserves a +1.
>
> However I have some concerns regarding the approach you're following.
>
> First, as we can expect that the quirkiness in current widget code is being
> utilized in various places in the dependent components, refactoring the
> widget code can lead to a multitude of issues regarding Screens and Forms
> in those components. I truly hope this will be as bad as I fear.
>
> Secondly, refactoring the widget code will have an impact on performance. I
> am sure we all hope (and some will expect it to be so) it is a positive
> effect, but we can't tell - at this moment in time - what it will be.
>
> Given the two concerns I would rather have seen that the refactoring was
> taking place in a separate development branch than in trunk. Having it done
> that way we would have the opportunity to compare the performance aspects
> of the refactored code against trunk (e.g. with Apache jMeter and such),
> and if favourable have another argument to tell to the users of old
> releases.
>
> Also while having the refactoring taking place in the development branch,
> we can not only isolate the aspects of my first concern (development branch
> issues vs trunk issues), but we will be able to better explain what the
> effects of the refactoring could be visavis (potential) issues of the users
> of old versions considering upgrading.
>
> 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 Sat, Jan 17, 2015 at 6:46 PM, Adrian Crum <
> adrian.crum@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
>>
>
Re: Widget Overhaul
Posted by Pierre Smits <pi...@gmail.com>.
Hi Adrian,
I am inclined to say that any code improvement that removes quirkiness in
current code or unpredictable behaviour while at the same time helping
contributors to develop better solutions deserves a +1.
However I have some concerns regarding the approach you're following.
First, as we can expect that the quirkiness in current widget code is being
utilized in various places in the dependent components, refactoring the
widget code can lead to a multitude of issues regarding Screens and Forms
in those components. I truly hope this will be as bad as I fear.
Secondly, refactoring the widget code will have an impact on performance. I
am sure we all hope (and some will expect it to be so) it is a positive
effect, but we can't tell - at this moment in time - what it will be.
Given the two concerns I would rather have seen that the refactoring was
taking place in a separate development branch than in trunk. Having it done
that way we would have the opportunity to compare the performance aspects
of the refactored code against trunk (e.g. with Apache jMeter and such),
and if favourable have another argument to tell to the users of old
releases.
Also while having the refactoring taking place in the development branch,
we can not only isolate the aspects of my first concern (development branch
issues vs trunk issues), but we will be able to better explain what the
effects of the refactoring could be visavis (potential) issues of the users
of old versions considering upgrading.
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 Sat, Jan 17, 2015 at 6:46 PM, Adrian Crum <
adrian.crum@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
>
Re: Widget Overhaul
Posted by Nicolas Malin <ni...@nereide.fr>.
Le 31/01/2015 00:28, Adrian Crum a écrit :
>
> The portlets are outside the scope of my current effort.
I understand, it's own effort to work on it ;)
Re: Widget Overhaul
Posted by Adrian Crum <ad...@sandglass-software.com>.
Take a look at the visitor design pattern I added and see if that will
accommodate your binary renderer. There is an example implementation in
XmlWidgetVisitor.java.
The portlets are outside the scope of my current effort.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/30/2015 12:31 PM, Nicolas Malin wrote:
> Hi Adrian, this work is welcome !
>
> The widget model is an important element to deploy OFBiz as an ERP and
> its own goal is to be improved to be more user-friendly and easy to
> maintain for developer.
>
> I see two axis that are missing at this time :
> * create high configurable portal page to offer the ability to orientate
> a screen on a business cover (business permission, portlet structure, ...)
> * Add a binary renderer to get the ability to create Xls flow from
> widget screens (xls or other) because at this time we can only use a
> string buffer
>
> With your overhaul proposition and the boostrap branch, we can have a
> screen killer framework ;)
>
> How can I help you actually ?
>
> Le 17/01/2015 18:46, Adrian Crum a écrit :
>> 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.
>>
>>
>
Re: Widget Overhaul
Posted by Nicolas Malin <ni...@nereide.fr>.
Hi Adrian, this work is welcome !
The widget model is an important element to deploy OFBiz as an ERP and
its own goal is to be improved to be more user-friendly and easy to
maintain for developer.
I see two axis that are missing at this time :
* create high configurable portal page to offer the ability to orientate
a screen on a business cover (business permission, portlet structure, ...)
* Add a binary renderer to get the ability to create Xls flow from
widget screens (xls or other) because at this time we can only use a
string buffer
With your overhaul proposition and the boostrap branch, we can have a
screen killer framework ;)
How can I help you actually ?
Le 17/01/2015 18:46, Adrian Crum a écrit :
> 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.
>
>