Re: Widget Overhaul
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=42=41 Jacques
Re: Widget Overhaul
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.car...@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
Re: Widget Overhaul
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
Re: Widget Overhaul
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,
Re: Widget Overhaul
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.car...@gmail.com
wrote:
What is the
Re: Widget Overhaul
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,
Re: Widget Overhaul
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.car...@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.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and
enhance UI
design. Furthermore, it will facilitate responsive design in
Ofbiz. I
agree that form widget should apply to forms. I would recommend
that we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases
it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I was overwhelmed by the quantity of source
code.
The screen widget library was built using a lot of copy-and-paste -
instead
of extracting and reusing common things. Scott started working on
reusing
widget code, but that was just a small beginning.
In
Re: Widget Overhaul
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.car...@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.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and
enhance UI
design. Furthermore, it will facilitate responsive design in
Ofbiz. I
agree that form widget should apply to forms. I would recommend
that we
create a table widget for multi-column lists instead of the
proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases
it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I was overwhelmed by the quantity of source
code.
The screen widget library was built using a lot of copy-and-paste
-
instead
of extracting and reusing common things. Scott started working on
reusing
widget code, but that was just a small beginning.
In a recent commit, I continued his work and made some more things
reusable.
Next, I would like to reorganize the source code folder structure.
Here
is
what I have pictured:
org/ofbiz/widget
artifact (Artifact Info classes)
cache (Widget cache classes)
model (Widget models)
renderer (Widget renderers)
macro
html
Re: Widget Overhaul
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.car...@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.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and
enhance UI
design. Furthermore, it will facilitate responsive design in
Ofbiz. I
agree that form widget should apply to forms. I would recommend
that we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases
it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I was overwhelmed by the quantity of source
code.
The screen widget library was built using a lot of copy-and-paste -
instead
of extracting and reusing common things. Scott started working on
reusing
widget code, but that was just a small beginning.
In a recent commit, I continued his work and made some more things
reusable.
Next, I would like to reorganize the source code folder structure.
Here
is
what I have pictured:
org/ofbiz/widget
artifact (Artifact Info classes)
cache (Widget cache classes)
model (Widget models)
renderer (Widget renderers)
macro
html
xml
I think the simplified folder structure makes more sense and it
will
make
it easier to locate classes.
After that, I would like to add error checking code to the widget
models
-
similar to what I did in
Re: Widget Overhaul
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.car...@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.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and
enhance UI
design. Furthermore, it will facilitate responsive design in
Ofbiz. I
agree that form widget should apply to forms. I would recommend
that we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases
it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I was overwhelmed by the quantity of source
code.
The screen widget library was built using a lot of copy-and-paste -
instead
of extracting and reusing common things. Scott started working on
reusing
widget code, but that was just a small beginning.
In a recent commit, I continued his work and made some more things
reusable.
Next, I would like to reorganize the
Re: Widget Overhaul
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.car...@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.c...@sandglass-software.com wrote: So, you're suggesting a grid widget would accept any screen widget within a cell? That could be done fairly easily. Adrian Crum Sandglass Software www.sandglass-software.com On 1/18/2015 8:49 PM, Gavin Mabie wrote: With columns already existing, rendering them inside rows would constitute a grid. On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: We have columns for that. Adrian Crum Sandglass Software www.sandglass-software.com On 1/17/2015 6:14 PM, Gavin Mabie wrote: Hi Adrian I like the grid idea. It will almost certainly simplify and enhance UI design. Furthermore, it will facilitate responsive design in Ofbiz. I agree that form widget should apply to forms. I would recommend that we create a table widget for multi-column lists instead of the proposed grid widget. My thinking is that the grid widget should be used as a layout widget on a level just beneath screens but higher than lower level widgets (screenlets/forms/tables/menus/trees). In other words a screen contains grids and grids contain lower level widgets. This pattern will enable us to make Ofbiz truly responsive. What do you think? Gavin On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
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.car...@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.c...@sandglass-software.com wrote: So, you're suggesting a grid widget would accept any screen widget within a cell? That could be done fairly easily. Adrian Crum Sandglass Software www.sandglass-software.com On 1/18/2015 8:49 PM, Gavin Mabie wrote: With columns already existing, rendering them inside rows would constitute a grid. On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: We have columns for that. Adrian Crum Sandglass Software www.sandglass-software.com On 1/17/2015 6:14 PM, Gavin Mabie wrote: Hi Adrian I like the grid idea. It will almost certainly simplify and enhance UI design. Furthermore, it will facilitate responsive design in Ofbiz. I agree that form widget should apply to forms. I would recommend that we create a table widget for multi-column lists instead of the proposed grid widget. My thinking is that the grid widget should be used as a layout widget on a level just beneath screens but higher than lower level widgets (screenlets/forms/tables/menus/trees). In other words a screen contains grids and grids contain lower level widgets. This pattern will enable us to make Ofbiz truly responsive. What do you think? Gavin On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget.
Re: Widget Overhaul
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.c...@sandglass-software.com wrote: So, you're suggesting a grid widget would accept any screen widget within a cell? That could be done fairly easily. Adrian Crum Sandglass Software www.sandglass-software.com On 1/18/2015 8:49 PM, Gavin Mabie wrote: With columns already existing, rendering them inside rows would constitute a grid. On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: We have columns for that. Adrian Crum Sandglass Software www.sandglass-software.com On 1/17/2015 6:14 PM, Gavin Mabie wrote: Hi Adrian I like the grid idea. It will almost certainly simplify and enhance UI design. Furthermore, it will facilitate responsive design in Ofbiz. I agree that form widget should apply to forms. I would recommend that we create a table widget for multi-column lists instead of the proposed grid widget. My thinking is that the grid widget should be used as a layout widget on a level just beneath screens but higher than lower level widgets (screenlets/forms/tables/menus/trees). In other words a screen contains grids and grids contain lower level widgets. This pattern will enable us to make Ofbiz truly responsive. What do you think? Gavin On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
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:
Re: Widget Overhaul
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
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 adrian.c...@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
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
Re: Widget Overhaul
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 adrian.c...@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
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 adrian.c...@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: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Widget Overhaul
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 adrian.c...@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
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
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 adrian.c...@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
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 adrian.c...@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: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Widget Overhaul
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 adrian.c...@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
On Jan 17, 2015, at 11:16 PM, Adrian Crum adrian.c...@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
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
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
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.c...@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 pierre.sm...@gmail.com
wrote:
I have created the placeholder for now:
https://issues.apache.org/jira/browse/OFBIZ-6034
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 4:24 PM, Pierre Smits pierre.sm...@gmail.com
wrote:
Ahh. Ok.
Thanks for the insights.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Right. The renderers need to be updated to render links consistently.
So
far, I have avoided touching the renderers. I will work on those later
if I
have time. Meanwhile, feel free to create a patch and I will apply it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 7:01 AM, Pierre Smits wrote:
Yes, I thought so too.
But when I use link in a Sreen.xml, like example below:
link link-type=ajax-window target=
newaction?partyId=${parameters.partyId} width=1000 height=400
text=
${uiLabelMap.CommonCreateNew} style=buttontext create/
I get a popup window.
Whereas when I use the same in a menu-item, like:
menu-item name=newaction title=${uiLabelMap.
SEPASetBankAttributes}
link link-type=ajax-window target=nAttributeLayer title=
${uiLabelMap.CommonCreateNew} width=1000 height=600
parameter param-name=partyId from-field=partyId/
/link
/menu-item
it doesn't open the screen in a popup wind, in stead it renders the
new
screen in the browser window.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
I did that already - in the schema and in code. There is a common
link
type, then the various widgets extend it to add their specific
attributes.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 1:45 AM, Pierre Smits wrote:
Hi Adrian,
Would it not be a good thing to have all the linking definition to
be
refactored to one single definiton?
Currently we have:
- link
- hyperlink
- sub-hyperlink
It seems to me that they are intended to deliver the same
functionality,
but are applied differently per application area:
1. link - menu, screen - but with different behaviour between
the
two,
e.g. ajax-window doesn't work in a menu
2. hyperlink - forms, commonly used to have a link associated
to a
field
3. sub-hyperlink - forms, commonly used in a display entity
associated
to a field
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie kwikst...@gmail.com
wrote:
Yes. Cell/Column sizes in conjunction with screen media
directives
can
then be used to achieve responsive layouts.
On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen
widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and
enhance
UI
design. Furthermore, it will facilitate responsive design in
Ofbiz. I
agree that form widget should apply to forms. I would recommend
that
we
create a table widget for
Re: Widget Overhaul
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 pierre.sm...@gmail.com
wrote:
I have created the placeholder for now:
https://issues.apache.org/jira/browse/OFBIZ-6034
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 4:24 PM, Pierre Smits pierre.sm...@gmail.com
wrote:
Ahh. Ok.
Thanks for the insights.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Right. The renderers need to be updated to render links consistently. So
far, I have avoided touching the renderers. I will work on those later if I
have time. Meanwhile, feel free to create a patch and I will apply it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 7:01 AM, Pierre Smits wrote:
Yes, I thought so too.
But when I use link in a Sreen.xml, like example below:
link link-type=ajax-window target=
newaction?partyId=${parameters.partyId} width=1000 height=400
text=
${uiLabelMap.CommonCreateNew} style=buttontext create/
I get a popup window.
Whereas when I use the same in a menu-item, like:
menu-item name=newaction title=${uiLabelMap.
SEPASetBankAttributes}
link link-type=ajax-window target=nAttributeLayer title=
${uiLabelMap.CommonCreateNew} width=1000 height=600
parameter param-name=partyId from-field=partyId/
/link
/menu-item
it doesn't open the screen in a popup wind, in stead it renders the new
screen in the browser window.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
I did that already - in the schema and in code. There is a common link
type, then the various widgets extend it to add their specific
attributes.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 1:45 AM, Pierre Smits wrote:
Hi Adrian,
Would it not be a good thing to have all the linking definition to be
refactored to one single definiton?
Currently we have:
- link
- hyperlink
- sub-hyperlink
It seems to me that they are intended to deliver the same
functionality,
but are applied differently per application area:
1. link - menu, screen - but with different behaviour between
the
two,
e.g. ajax-window doesn't work in a menu
2. hyperlink - forms, commonly used to have a link associated
to a
field
3. sub-hyperlink - forms, commonly used in a display entity
associated
to a field
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie kwikst...@gmail.com
wrote:
Yes. Cell/Column sizes in conjunction with screen media directives
can
then be used to achieve responsive layouts.
On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and
enhance
UI
design. Furthermore, it will facilitate responsive design in
Ofbiz. I
agree that form widget should apply to forms. I would recommend
that
we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat,
Re: Widget Overhaul
Adrian,
Could you update http://ofbiz.apache.org/dtds/ so that the underlaying xsd
files reflect the recent changes?
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 5:01 PM, Pierre Smits pierre.sm...@gmail.com
wrote:
I have created the placeholder for now:
https://issues.apache.org/jira/browse/OFBIZ-6034
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 4:24 PM, Pierre Smits pierre.sm...@gmail.com
wrote:
Ahh. Ok.
Thanks for the insights.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Right. The renderers need to be updated to render links consistently. So
far, I have avoided touching the renderers. I will work on those later if I
have time. Meanwhile, feel free to create a patch and I will apply it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 7:01 AM, Pierre Smits wrote:
Yes, I thought so too.
But when I use link in a Sreen.xml, like example below:
link link-type=ajax-window target=
newaction?partyId=${parameters.partyId} width=1000 height=400
text=
${uiLabelMap.CommonCreateNew} style=buttontext create/
I get a popup window.
Whereas when I use the same in a menu-item, like:
menu-item name=newaction title=${uiLabelMap.
SEPASetBankAttributes}
link link-type=ajax-window target=nAttributeLayer title=
${uiLabelMap.CommonCreateNew} width=1000 height=600
parameter param-name=partyId from-field=partyId/
/link
/menu-item
it doesn't open the screen in a popup wind, in stead it renders the new
screen in the browser window.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
I did that already - in the schema and in code. There is a common link
type, then the various widgets extend it to add their specific
attributes.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 1:45 AM, Pierre Smits wrote:
Hi Adrian,
Would it not be a good thing to have all the linking definition to be
refactored to one single definiton?
Currently we have:
- link
- hyperlink
- sub-hyperlink
It seems to me that they are intended to deliver the same
functionality,
but are applied differently per application area:
1. link - menu, screen - but with different behaviour between
the
two,
e.g. ajax-window doesn't work in a menu
2. hyperlink - forms, commonly used to have a link associated
to a
field
3. sub-hyperlink - forms, commonly used in a display entity
associated
to a field
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie kwikst...@gmail.com
wrote:
Yes. Cell/Column sizes in conjunction with screen media directives
can
then be used to achieve responsive layouts.
On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and
enhance
UI
design. Furthermore, it will facilitate responsive design in
Ofbiz. I
agree that form widget should apply to forms. I would recommend
that
we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum
Re: Widget Overhaul
Hi Adrian, Would it not be a good thing to have all the linking definition to be refactored to one single definiton? Currently we have: - link - hyperlink - sub-hyperlink It seems to me that they are intended to deliver the same functionality, but are applied differently per application area: 1. link - menu, screen - but with different behaviour between the two, e.g. ajax-window doesn't work in a menu 2. hyperlink - forms, commonly used to have a link associated to a field 3. sub-hyperlink - forms, commonly used in a display entity associated to a field Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie kwikst...@gmail.com wrote: Yes. Cell/Column sizes in conjunction with screen media directives can then be used to achieve responsive layouts. On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: So, you're suggesting a grid widget would accept any screen widget within a cell? That could be done fairly easily. Adrian Crum Sandglass Software www.sandglass-software.com On 1/18/2015 8:49 PM, Gavin Mabie wrote: With columns already existing, rendering them inside rows would constitute a grid. On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: We have columns for that. Adrian Crum Sandglass Software www.sandglass-software.com On 1/17/2015 6:14 PM, Gavin Mabie wrote: Hi Adrian I like the grid idea. It will almost certainly simplify and enhance UI design. Furthermore, it will facilitate responsive design in Ofbiz. I agree that form widget should apply to forms. I would recommend that we create a table widget for multi-column lists instead of the proposed grid widget. My thinking is that the grid widget should be used as a layout widget on a level just beneath screens but higher than lower level widgets (screenlets/forms/tables/menus/trees). In other words a screen contains grids and grids contain lower level widgets. This pattern will enable us to make Ofbiz truly responsive. What do you think? Gavin On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
I did that already - in the schema and in code. There is a common link type, then the various widgets extend it to add their specific attributes. Adrian Crum Sandglass Software www.sandglass-software.com On 1/23/2015 1:45 AM, Pierre Smits wrote: Hi Adrian, Would it not be a good thing to have all the linking definition to be refactored to one single definiton? Currently we have: - link - hyperlink - sub-hyperlink It seems to me that they are intended to deliver the same functionality, but are applied differently per application area: 1. link - menu, screen - but with different behaviour between the two, e.g. ajax-window doesn't work in a menu 2. hyperlink - forms, commonly used to have a link associated to a field 3. sub-hyperlink - forms, commonly used in a display entity associated to a field Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie kwikst...@gmail.com wrote: Yes. Cell/Column sizes in conjunction with screen media directives can then be used to achieve responsive layouts. On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: So, you're suggesting a grid widget would accept any screen widget within a cell? That could be done fairly easily. Adrian Crum Sandglass Software www.sandglass-software.com On 1/18/2015 8:49 PM, Gavin Mabie wrote: With columns already existing, rendering them inside rows would constitute a grid. On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: We have columns for that. Adrian Crum Sandglass Software www.sandglass-software.com On 1/17/2015 6:14 PM, Gavin Mabie wrote: Hi Adrian I like the grid idea. It will almost certainly simplify and enhance UI design. Furthermore, it will facilitate responsive design in Ofbiz. I agree that form widget should apply to forms. I would recommend that we create a table widget for multi-column lists instead of the proposed grid widget. My thinking is that the grid widget should be used as a layout widget on a level just beneath screens but higher than lower level widgets (screenlets/forms/tables/menus/trees). In other words a screen contains grids and grids contain lower level widgets. This pattern will enable us to make Ofbiz truly responsive. What do you think? Gavin On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
Right. The renderers need to be updated to render links consistently. So
far, I have avoided touching the renderers. I will work on those later
if I have time. Meanwhile, feel free to create a patch and I will apply it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 7:01 AM, Pierre Smits wrote:
Yes, I thought so too.
But when I use link in a Sreen.xml, like example below:
link link-type=ajax-window target=
newaction?partyId=${parameters.partyId} width=1000 height=400 text=
${uiLabelMap.CommonCreateNew} style=buttontext create/
I get a popup window.
Whereas when I use the same in a menu-item, like:
menu-item name=newaction title=${uiLabelMap.SEPASetBankAttributes}
link link-type=ajax-window target=nAttributeLayer title=
${uiLabelMap.CommonCreateNew} width=1000 height=600
parameter param-name=partyId from-field=partyId/
/link
/menu-item
it doesn't open the screen in a popup wind, in stead it renders the new
screen in the browser window.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
I did that already - in the schema and in code. There is a common link
type, then the various widgets extend it to add their specific attributes.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 1:45 AM, Pierre Smits wrote:
Hi Adrian,
Would it not be a good thing to have all the linking definition to be
refactored to one single definiton?
Currently we have:
- link
- hyperlink
- sub-hyperlink
It seems to me that they are intended to deliver the same functionality,
but are applied differently per application area:
1. link - menu, screen - but with different behaviour between the
two,
e.g. ajax-window doesn't work in a menu
2. hyperlink - forms, commonly used to have a link associated to a
field
3. sub-hyperlink - forms, commonly used in a display entity
associated
to a field
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie kwikst...@gmail.com wrote:
Yes. Cell/Column sizes in conjunction with screen media directives can
then be used to achieve responsive layouts.
On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and enhance
UI
design. Furthermore, it will facilitate responsive design in Ofbiz. I
agree that form widget should apply to forms. I would recommend that
we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I was overwhelmed by the quantity of source
code.
The screen widget library was built using a lot of copy-and-paste -
instead
of extracting and reusing common things. Scott started working on
reusing
widget code, but that was just a small beginning.
In a recent commit, I continued his work and made some more things
reusable.
Next, I would like to reorganize the source code folder structure.
Here
is
what I have pictured:
org/ofbiz/widget
artifact (Artifact Info classes)
cache (Widget cache classes)
model (Widget models)
renderer (Widget renderers)
macro
html
xml
I think the simplified folder structure makes more sense and it will
make
it easier to locate classes.
After that, I would like to add error
Re: Widget Overhaul
Ahh. Ok.
Thanks for the insights.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Right. The renderers need to be updated to render links consistently. So
far, I have avoided touching the renderers. I will work on those later if I
have time. Meanwhile, feel free to create a patch and I will apply it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 7:01 AM, Pierre Smits wrote:
Yes, I thought so too.
But when I use link in a Sreen.xml, like example below:
link link-type=ajax-window target=
newaction?partyId=${parameters.partyId} width=1000 height=400 text=
${uiLabelMap.CommonCreateNew} style=buttontext create/
I get a popup window.
Whereas when I use the same in a menu-item, like:
menu-item name=newaction title=${uiLabelMap.
SEPASetBankAttributes}
link link-type=ajax-window target=nAttributeLayer title=
${uiLabelMap.CommonCreateNew} width=1000 height=600
parameter param-name=partyId from-field=partyId/
/link
/menu-item
it doesn't open the screen in a popup wind, in stead it renders the new
screen in the browser window.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
I did that already - in the schema and in code. There is a common link
type, then the various widgets extend it to add their specific
attributes.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 1:45 AM, Pierre Smits wrote:
Hi Adrian,
Would it not be a good thing to have all the linking definition to be
refactored to one single definiton?
Currently we have:
- link
- hyperlink
- sub-hyperlink
It seems to me that they are intended to deliver the same functionality,
but are applied differently per application area:
1. link - menu, screen - but with different behaviour between the
two,
e.g. ajax-window doesn't work in a menu
2. hyperlink - forms, commonly used to have a link associated to a
field
3. sub-hyperlink - forms, commonly used in a display entity
associated
to a field
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie kwikst...@gmail.com
wrote:
Yes. Cell/Column sizes in conjunction with screen media directives
can
then be used to achieve responsive layouts.
On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and
enhance
UI
design. Furthermore, it will facilitate responsive design in Ofbiz. I
agree that form widget should apply to forms. I would recommend that
we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I was overwhelmed by the quantity of source
code.
The screen widget library was built using a lot of copy-and-paste
-
instead
of extracting and reusing common things. Scott started working on
reusing
widget code, but that was just a small beginning.
In a recent commit, I continued his work and made some more things
reusable.
Next, I
Re: Widget Overhaul
I have created the placeholder for now:
https://issues.apache.org/jira/browse/OFBIZ-6034
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 4:24 PM, Pierre Smits pierre.sm...@gmail.com
wrote:
Ahh. Ok.
Thanks for the insights.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Right. The renderers need to be updated to render links consistently. So
far, I have avoided touching the renderers. I will work on those later if I
have time. Meanwhile, feel free to create a patch and I will apply it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 7:01 AM, Pierre Smits wrote:
Yes, I thought so too.
But when I use link in a Sreen.xml, like example below:
link link-type=ajax-window target=
newaction?partyId=${parameters.partyId} width=1000 height=400
text=
${uiLabelMap.CommonCreateNew} style=buttontext create/
I get a popup window.
Whereas when I use the same in a menu-item, like:
menu-item name=newaction title=${uiLabelMap.
SEPASetBankAttributes}
link link-type=ajax-window target=nAttributeLayer title=
${uiLabelMap.CommonCreateNew} width=1000 height=600
parameter param-name=partyId from-field=partyId/
/link
/menu-item
it doesn't open the screen in a popup wind, in stead it renders the new
screen in the browser window.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
I did that already - in the schema and in code. There is a common link
type, then the various widgets extend it to add their specific
attributes.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 1:45 AM, Pierre Smits wrote:
Hi Adrian,
Would it not be a good thing to have all the linking definition to be
refactored to one single definiton?
Currently we have:
- link
- hyperlink
- sub-hyperlink
It seems to me that they are intended to deliver the same
functionality,
but are applied differently per application area:
1. link - menu, screen - but with different behaviour between the
two,
e.g. ajax-window doesn't work in a menu
2. hyperlink - forms, commonly used to have a link associated to
a
field
3. sub-hyperlink - forms, commonly used in a display entity
associated
to a field
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie kwikst...@gmail.com
wrote:
Yes. Cell/Column sizes in conjunction with screen media directives
can
then be used to achieve responsive layouts.
On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and
enhance
UI
design. Furthermore, it will facilitate responsive design in Ofbiz.
I
agree that form widget should apply to forms. I would recommend
that
we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I
Re: Widget Overhaul
Yes, I thought so too.
But when I use link in a Sreen.xml, like example below:
link link-type=ajax-window target=
newaction?partyId=${parameters.partyId} width=1000 height=400 text=
${uiLabelMap.CommonCreateNew} style=buttontext create/
I get a popup window.
Whereas when I use the same in a menu-item, like:
menu-item name=newaction title=${uiLabelMap.SEPASetBankAttributes}
link link-type=ajax-window target=nAttributeLayer title=
${uiLabelMap.CommonCreateNew} width=1000 height=600
parameter param-name=partyId from-field=partyId/
/link
/menu-item
it doesn't open the screen in a popup wind, in stead it renders the new
screen in the browser window.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
I did that already - in the schema and in code. There is a common link
type, then the various widgets extend it to add their specific attributes.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 1:45 AM, Pierre Smits wrote:
Hi Adrian,
Would it not be a good thing to have all the linking definition to be
refactored to one single definiton?
Currently we have:
- link
- hyperlink
- sub-hyperlink
It seems to me that they are intended to deliver the same functionality,
but are applied differently per application area:
1. link - menu, screen - but with different behaviour between the
two,
e.g. ajax-window doesn't work in a menu
2. hyperlink - forms, commonly used to have a link associated to a
field
3. sub-hyperlink - forms, commonly used in a display entity
associated
to a field
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie kwikst...@gmail.com wrote:
Yes. Cell/Column sizes in conjunction with screen media directives can
then be used to achieve responsive layouts.
On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and enhance
UI
design. Furthermore, it will facilitate responsive design in Ofbiz. I
agree that form widget should apply to forms. I would recommend that
we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I was overwhelmed by the quantity of source
code.
The screen widget library was built using a lot of copy-and-paste -
instead
of extracting and reusing common things. Scott started working on
reusing
widget code, but that was just a small beginning.
In a recent commit, I continued his work and made some more things
reusable.
Next, I would like to reorganize the source code folder structure.
Here
is
what I have pictured:
org/ofbiz/widget
artifact (Artifact Info classes)
cache (Widget cache classes)
model (Widget models)
renderer (Widget renderers)
macro
html
xml
I think the simplified folder structure makes more sense and it will
make
it easier to locate classes.
After that, I would like to add error checking code to the widget
models
-
similar to what I did in Mini-Language. Right now, errors in widget
XML
are
(sometimes) logged and widget parsing continues. If a developer does
something wrong, they will not know it unless they check the logs. I
would
like to
Re: Widget Overhaul
So I can use ajax-window in a screen, but then must I resort to a complex
setup in a section with regards to conditon settings to get an ajax window.
Or when using a menu and menu item to utilise conditions, I must resort to
calling a javascript to get an ajax window.
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 4:01 PM, Pierre Smits pierre.sm...@gmail.com
wrote:
Yes, I thought so too.
But when I use link in a Sreen.xml, like example below:
link link-type=ajax-window target=
newaction?partyId=${parameters.partyId} width=1000 height=400 text=
${uiLabelMap.CommonCreateNew} style=buttontext create/
I get a popup window.
Whereas when I use the same in a menu-item, like:
menu-item name=newaction title=${uiLabelMap.SEPASetBankAttributes}
link link-type=ajax-window target=nAttributeLayer title=
${uiLabelMap.CommonCreateNew} width=1000 height=600
parameter param-name=partyId from-field=partyId/
/link
/menu-item
it doesn't open the screen in a popup wind, in stead it renders the new
screen in the browser window.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
I did that already - in the schema and in code. There is a common link
type, then the various widgets extend it to add their specific attributes.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/23/2015 1:45 AM, Pierre Smits wrote:
Hi Adrian,
Would it not be a good thing to have all the linking definition to be
refactored to one single definiton?
Currently we have:
- link
- hyperlink
- sub-hyperlink
It seems to me that they are intended to deliver the same functionality,
but are applied differently per application area:
1. link - menu, screen - but with different behaviour between the
two,
e.g. ajax-window doesn't work in a menu
2. hyperlink - forms, commonly used to have a link associated to a
field
3. sub-hyperlink - forms, commonly used in a display entity
associated
to a field
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie kwikst...@gmail.com
wrote:
Yes. Cell/Column sizes in conjunction with screen media directives can
then be used to achieve responsive layouts.
On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and enhance
UI
design. Furthermore, it will facilitate responsive design in Ofbiz. I
agree that form widget should apply to forms. I would recommend
that
we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I was overwhelmed by the quantity of source
code.
The screen widget library was built using a lot of copy-and-paste -
instead
of extracting and reusing common things. Scott started working on
reusing
widget code, but that was just a small beginning.
In a recent commit, I continued his work and made some more things
reusable.
Next, I would like to reorganize the source code folder structure.
Here
is
what I have pictured:
org/ofbiz/widget
artifact (Artifact Info classes)
cache (Widget cache
Re: Widget Overhaul
So, you're suggesting a grid widget would accept any screen widget within a cell? That could be done fairly easily. Adrian Crum Sandglass Software www.sandglass-software.com On 1/18/2015 8:49 PM, Gavin Mabie wrote: With columns already existing, rendering them inside rows would constitute a grid. On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: We have columns for that. Adrian Crum Sandglass Software www.sandglass-software.com On 1/17/2015 6:14 PM, Gavin Mabie wrote: Hi Adrian I like the grid idea. It will almost certainly simplify and enhance UI design. Furthermore, it will facilitate responsive design in Ofbiz. I agree that form widget should apply to forms. I would recommend that we create a table widget for multi-column lists instead of the proposed grid widget. My thinking is that the grid widget should be used as a layout widget on a level just beneath screens but higher than lower level widgets (screenlets/forms/tables/menus/trees). In other words a screen contains grids and grids contain lower level widgets. This pattern will enable us to make Ofbiz truly responsive. What do you think? Gavin On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
Yes. Cell/Column sizes in conjunction with screen media directives can then be used to achieve responsive layouts. On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: So, you're suggesting a grid widget would accept any screen widget within a cell? That could be done fairly easily. Adrian Crum Sandglass Software www.sandglass-software.com On 1/18/2015 8:49 PM, Gavin Mabie wrote: With columns already existing, rendering them inside rows would constitute a grid. On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: We have columns for that. Adrian Crum Sandglass Software www.sandglass-software.com On 1/17/2015 6:14 PM, Gavin Mabie wrote: Hi Adrian I like the grid idea. It will almost certainly simplify and enhance UI design. Furthermore, it will facilitate responsive design in Ofbiz. I agree that form widget should apply to forms. I would recommend that we create a table widget for multi-column lists instead of the proposed grid widget. My thinking is that the grid widget should be used as a layout widget on a level just beneath screens but higher than lower level widgets (screenlets/forms/tables/menus/trees). In other words a screen contains grids and grids contain lower level widgets. This pattern will enable us to make Ofbiz truly responsive. What do you think? Gavin On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
With columns already existing, rendering them inside rows would constitute a grid. On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: We have columns for that. Adrian Crum Sandglass Software www.sandglass-software.com On 1/17/2015 6:14 PM, Gavin Mabie wrote: Hi Adrian I like the grid idea. It will almost certainly simplify and enhance UI design. Furthermore, it will facilitate responsive design in Ofbiz. I agree that form widget should apply to forms. I would recommend that we create a table widget for multi-column lists instead of the proposed grid widget. My thinking is that the grid widget should be used as a layout widget on a level just beneath screens but higher than lower level widgets (screenlets/forms/tables/menus/trees). In other words a screen contains grids and grids contain lower level widgets. This pattern will enable us to make Ofbiz truly responsive. What do you think? Gavin On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
We have columns for that. Adrian Crum Sandglass Software www.sandglass-software.com On 1/17/2015 6:14 PM, Gavin Mabie wrote: Hi Adrian I like the grid idea. It will almost certainly simplify and enhance UI design. Furthermore, it will facilitate responsive design in Ofbiz. I agree that form widget should apply to forms. I would recommend that we create a table widget for multi-column lists instead of the proposed grid widget. My thinking is that the grid widget should be used as a layout widget on a level just beneath screens but higher than lower level widgets (screenlets/forms/tables/menus/trees). In other words a screen contains grids and grids contain lower level widgets. This pattern will enable us to make Ofbiz truly responsive. What do you think? Gavin On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
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.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
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.c...@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.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
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.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
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.c...@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.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Widget Overhaul
Hi Adrian I like the grid idea. It will almost certainly simplify and enhance UI design. Furthermore, it will facilitate responsive design in Ofbiz. I agree that form widget should apply to forms. I would recommend that we create a table widget for multi-column lists instead of the proposed grid widget. My thinking is that the grid widget should be used as a layout widget on a level just beneath screens but higher than lower level widgets (screenlets/forms/tables/menus/trees). In other words a screen contains grids and grids contain lower level widgets. This pattern will enable us to make Ofbiz truly responsive. What do you think? Gavin On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some time ago I started working on the screen widget thread safety. There were many places in code where widget models were being modified during rendering - resulting in unpredictable behavior, and in some cases it resulted in users having access to data they shouldn't be able to see. While doing that work, I was overwhelmed by the quantity of source code. The screen widget library was built using a lot of copy-and-paste - instead of extracting and reusing common things. Scott started working on reusing widget code, but that was just a small beginning. In a recent commit, I continued his work and made some more things reusable. Next, I would like to reorganize the source code folder structure. Here is what I have pictured: org/ofbiz/widget artifact (Artifact Info classes) cache (Widget cache classes) model (Widget models) renderer (Widget renderers) macro html xml I think the simplified folder structure makes more sense and it will make it easier to locate classes. After that, I would like to add error checking code to the widget models - similar to what I did in Mini-Language. Right now, errors in widget XML are (sometimes) logged and widget parsing continues. If a developer does something wrong, they will not know it unless they check the logs. I would like to change the behavior so widget XML errors throw an exception with a detailed error message that includes the XML file name and line number where the error occurred. I believe this will benefit developers by making it clear when they have done something wrong. Finally, I would like to extract list functionality from the form widget and create a new grid widget. So, instead of a form widget representing a single data entry form OR a list, it will ONLY represent a single form. If you want a list, you use the grid widget. Initially, this change will be backwards-compatible - the XML parser will accept a form element for both types and it will create the correct model based on the type attribute. Overall, my goal is to make screen widgets more developer-friendly, and also to make it easier to innovate in the screen widget component. After all of this work is completed, I would like to backport it to the R14 branch. Comments are welcome. -- Adrian Crum Sandglass Software www.sandglass-software.com
