Widget Overhaul

[Jacques Le Roux]

This is something I really want to do now, I will try to remove as much as possible things from Confluence!

Jacques

Le 11/02/2015 23:23, Jacques Le Roux a écrit :
> Actually it's more simple than that. It's explained in the Download page and there is also a README in the "OFBiz root (folder)"
> Maybe we should think otherwise and remove all things in the wiki which might not been ALWAYS maintained.
> From this conversation I begin to wonder if it's not the right solution. Keep the documentation as simple as possible!

[Ron Wheeler]

+1
We should be careful about adding things to the project infrastructure.
If it will not be kept up to date, don't add it into the main sections.

Things that are private musings or a best partial specifications of a
potential enhancement should be clearly marked as such and kept out of
the view of someone trying to get started with OFBiz.

The current effort should help identify and clean up the important items
and move old stuff to the archives.
We can be a bit ruthless since nothing is really lost forever.

Ron

On 12/02/2015 2:40 AM, Jacques Le Roux wrote:

> This is something I really want to do now, I will try to remove as
> much as possible things from Confluence!
>
> Jacques
>
> Le 11/02/2015 23:23, Jacques Le Roux a écrit :
>> Actually it's more simple than that. It's explained in the Download
>> page and there is also a README in the "OFBiz root (folder)"
>> Maybe we should think otherwise and remove all things in the wiki
>> which might not been ALWAYS maintained.
>> From this conversation I begin to wonder if it's not the right
>> solution. Keep the documentation as simple as possible!
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Christian Carlow-OFBizzer]

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 <
> [hidden email]> 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 <
> >> [hidden email]> 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 <
> >>>> [hidden email]> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>

[Pierre Smits]

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 <[hidden email]
> 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 <
> > [hidden email]> 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 <
> > >> [hidden email]> 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 <
> > >>>> [hidden email]> 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
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>
>
>
>

[Christian Carlow-OFBizzer]

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 <[hidden email]
> > 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 <
> > > [hidden email]> 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 <
> > > >> [hidden email]> 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 <
> > > >>>> [hidden email]> 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
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>
> >
> >
> >

[Christian Carlow-OFBizzer]

<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 <[hidden email]
> > > 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 <
> > > > [hidden email]> 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 <
> > > > >> [hidden email]> 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 <
> > > > >>>> [hidden email]> 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
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>
> > >
> > >
> > >
>
>

[Adrian Crum-3]

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 <[hidden email]
>>>> 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 <
>>>>> [hidden email]> 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 <
>>>>>>> [hidden email]> 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 <
>>>>>>>>> [hidden email]> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>
>>
>
>

[Christian Carlow-OFBizzer]

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 <[hidden email]
> >>>> 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 <
> >>>>> [hidden email]> 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 <
> >>>>>>> [hidden email]> 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 <
> >>>>>>>>> [hidden email]> 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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >
> >

[Adrian Crum-3]

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 <[hidden email]
>>>>>> 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 <
>>>>>>> [hidden email]> 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 <
>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>> [hidden email]> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>
>

[Christian Carlow-OFBizzer]

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 <[hidden email]
> >>>>>> 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 <
> >>>>>>> [hidden email]> 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 <
> >>>>>>>>> [hidden email]> 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 <
> >>>>>>>>>>> [hidden email]> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >
> >

[Adrian Crum-3]

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 <[hidden email]
>>>>>>>> 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 <
>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>>>> [hidden email]> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

[Christian Carlow-OFBizzer]

Thanks Adrian and sorry for the misunderstanding, you are right grids
are rendered as tables.

The embedded menu rendering functionality provided by Nicolas in
OFBIZ-6404 needs to be modified so that menus are rendered outside of
any forms that may be created for grid row submissions.  As of right now
menus behave like edit fields and trigger the creation of an html form
element wrapper.

I will patch OFBIZ-6404 so that menus always get rendered outside of row
edit forms in case of link-type="hidden-form".  Then I will implement
screen and form/grid embedding in a similar manner.

Thanks again for your help.

On Sun, 2015-06-14 at 09:12 -0700, Adrian Crum wrote:

> I thought a grid is rendered as a <table> element, I was not aware that
> it is rendered as a <form> element.
>
> Grids do not support including screens. That feature was suggested
> before, and it would be a nice one to have. Actually, it would be nice
> if grid and form widgets worked more like the screen widget - with
> sections that can be controlled by conditional elements.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 6/14/2015 3:03 AM, Christian Carlow wrote:
> > Thanks for the feedback Adrian.
> >
> > I check commit logs and see the grid widget additions back in January
> > that you recommended using for OFBIZ-6402 which I did.
> >
> > But grids don't appear to support embedding of screens.  Is this
> > something that is intended to be added later?
> >
> > If so, the difficulty is how to handle embedding of screens containing
> > forms when grid itself is already rendered as an html form element which
> > doesn't allow embedding of other form elements.
> >
> > This problem is demonstrated by OFBIZ-6404 where Nicolas added support
> > for menu embedding which only works if menu links are not rendered as
> > hidden forms.  Whenever the embedded menus are rendered as hidden forms
> > the links no longer work.
> >
> > I found no grid widget JIRAs and therefore don't know how to proceed to
> > support screen widget embedding within a table list.
> >
> > I started implementing <iterate-table> based on <iterate-section> but
> > with <column> as the child elements as an alternate way to generate a
> > table list than with grid.  This delivered the functionality I needed
> > but still needs improvements that seem redundantly supported by the grid
> > widget already, such as support for even and odd row coloring, column
> > titles etc.
> >
> > I'm trying to get some feedback as soon as possible so that I can make a
> > decision to continue on with the enhancements to <iterate-table> or to
> > abondon the <iterate-table> functionality already started and instead
> > pursue implementing screen embedding support for <grid>.
> >
> > For example:
> > <iterate-table entry="partyMap" list="partyMaps"
> > odd-row-style="alt-row">
> > <column title="${uiLabelMap.partyId}">
> > <label text="${partyMap.partyId}"
> > </column>
> > <column title="${uiLabelMap.partyAddress}">
> > <include-screen name="ViewPostalAddress"
> > location="component://party/widget/PartyScreens.xml"/>
> > </column>
> > </iterate-table>
> >
> > On Thu, 2015-06-11 at 23:10 -0700, Adrian Crum wrote:
> >> The grid widget is implemented. Please check the commit logs.
> >>
> >> The column widget is not intended to implement a grid. It is intended to
> >> be used for multi-column layout of screens (like newspaper columns).
> >>
> >> Adrian Crum
> >> Sandglass Software
> >> www.sandglass-software.com
> >>
> >> On 6/11/2015 2:57 PM, Christian Carlow wrote:
> >>> Adrian,
> >>>
> >>> So grid widget isn't implemented yet?
> >>>
> >>> Is there a JIRA for it?
> >>>
> >>> Would my proposal for <iterate-column> conflict with it's
> >>> implementation?
> >>>
> >>> If not, would <iterate-column> be worthy of a JIRA?
> >>>
> >>> On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
> >>>> The column widget is intended to be used for multi-column layout. It is
> >>>> not a replacement for a grid widget.
> >>>>
> >>>> Adrian Crum
> >>>> Sandglass Software
> >>>> www.sandglass-software.com
> >>>>
> >>>> On 6/11/2015 1:21 PM, Christian Carlow wrote:
> >>>>> <column-container> and <column> screen widgets seem to have been
> >>>>> implemented based on the discussion and JIRAs, but creating a single
> >>>>> table to contain a list doesn't seem supported for screens yet.  The
> >>>>> following creates multiple tables for each <column-container>:
> >>>>>
> >>>>> <iterate-section>
> >>>>> <column-container>
> >>>>> <column>
> >>>>> </column>
> >>>>> </column-container>
> >>>>> </iterate-section>
> >>>>>
> >>>>> Should something like the following be supported to implement single
> >>>>> table functionality:
> >>>>>
> >>>>> <iterate-column list="listIt" style="basic-table" row-style="${groovy:
> >>>>> if(rowCount%2==0) 'alternate-row'}">
> >>>>> <column title="partyId">
> >>>>> </column>
> >>>>> <column title="partyName">
> >>>>> </column>
> >>>>> </iterate-column>
> >>>>>
> >>>>> Each iteration could create a row and row-style could be set using
> >>>>> FlexibleStringExpander for groovy conditions.  <column-titles> would
> >>>>> create 1 extra row at the top which may be empty.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
> >>>>>> Thanks for the pointer Pierre.
> >>>>>>
> >>>>>> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
> >>>>>> being supported by the form menu embedding functionality because html
> >>>>>> forms cannot be nested.  It seems the grid or column functionality will
> >>>>>> allow forms to be embedded in columns of table lists.  Therefore
> >>>>>> OFBIZ-6404 probably isn't related since it implements a different
> >>>>>> approach to menu/form embedding.
> >>>>>>
> >>>>>> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
> >>>>>>> Various JIRA issues have been created, and several addressed/resolved. See
> >>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
> >>>>>>> (does not link all).
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>> Pierre Smits
> >>>>>>>
> >>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
> >>>>>>> Services & Solutions for Cloud-
> >>>>>>> Based Manufacturing, Professional
> >>>>>>> Services and Retail & Trade
> >>>>>>> http://www.orrtiz.com
> >>>>>>>
> >>>>>>> On Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <[hidden email]
> >>>>>>>> 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 <
> >>>>>>>>> [hidden email]> 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 <
> >>>>>>>>>>> [hidden email]> 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 <
> >>>>>>>>>>>>> [hidden email]> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
> >

[Adrian Crum-3]

Keep in mind that menu items are rendered as forms for a reason - to
fight XSS attacks. So, whatever solution you have in mind should not
change that behavior.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 6/14/2015 10:05 AM, Christian Carlow wrote:

> Thanks Adrian and sorry for the misunderstanding, you are right grids
> are rendered as tables.
>
> The embedded menu rendering functionality provided by Nicolas in
> OFBIZ-6404 needs to be modified so that menus are rendered outside of
> any forms that may be created for grid row submissions.  As of right now
> menus behave like edit fields and trigger the creation of an html form
> element wrapper.
>
> I will patch OFBIZ-6404 so that menus always get rendered outside of row
> edit forms in case of link-type="hidden-form".  Then I will implement
> screen and form/grid embedding in a similar manner.
>
> Thanks again for your help.
>
> On Sun, 2015-06-14 at 09:12 -0700, Adrian Crum wrote:
>> I thought a grid is rendered as a <table> element, I was not aware that
>> it is rendered as a <form> element.
>>
>> Grids do not support including screens. That feature was suggested
>> before, and it would be a nice one to have. Actually, it would be nice
>> if grid and form widgets worked more like the screen widget - with
>> sections that can be controlled by conditional elements.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 6/14/2015 3:03 AM, Christian Carlow wrote:
>>> Thanks for the feedback Adrian.
>>>
>>> I check commit logs and see the grid widget additions back in January
>>> that you recommended using for OFBIZ-6402 which I did.
>>>
>>> But grids don't appear to support embedding of screens.  Is this
>>> something that is intended to be added later?
>>>
>>> If so, the difficulty is how to handle embedding of screens containing
>>> forms when grid itself is already rendered as an html form element which
>>> doesn't allow embedding of other form elements.
>>>
>>> This problem is demonstrated by OFBIZ-6404 where Nicolas added support
>>> for menu embedding which only works if menu links are not rendered as
>>> hidden forms.  Whenever the embedded menus are rendered as hidden forms
>>> the links no longer work.
>>>
>>> I found no grid widget JIRAs and therefore don't know how to proceed to
>>> support screen widget embedding within a table list.
>>>
>>> I started implementing <iterate-table> based on <iterate-section> but
>>> with <column> as the child elements as an alternate way to generate a
>>> table list than with grid.  This delivered the functionality I needed
>>> but still needs improvements that seem redundantly supported by the grid
>>> widget already, such as support for even and odd row coloring, column
>>> titles etc.
>>>
>>> I'm trying to get some feedback as soon as possible so that I can make a
>>> decision to continue on with the enhancements to <iterate-table> or to
>>> abondon the <iterate-table> functionality already started and instead
>>> pursue implementing screen embedding support for <grid>.
>>>
>>> For example:
>>> <iterate-table entry="partyMap" list="partyMaps"
>>> odd-row-style="alt-row">
>>> <column title="${uiLabelMap.partyId}">
>>> <label text="${partyMap.partyId}"
>>> </column>
>>> <column title="${uiLabelMap.partyAddress}">
>>> <include-screen name="ViewPostalAddress"
>>> location="component://party/widget/PartyScreens.xml"/>
>>> </column>
>>> </iterate-table>
>>>
>>> On Thu, 2015-06-11 at 23:10 -0700, Adrian Crum wrote:
>>>> The grid widget is implemented. Please check the commit logs.
>>>>
>>>> The column widget is not intended to implement a grid. It is intended to
>>>> be used for multi-column layout of screens (like newspaper columns).
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 6/11/2015 2:57 PM, Christian Carlow wrote:
>>>>> Adrian,
>>>>>
>>>>> So grid widget isn't implemented yet?
>>>>>
>>>>> Is there a JIRA for it?
>>>>>
>>>>> Would my proposal for <iterate-column> conflict with it's
>>>>> implementation?
>>>>>
>>>>> If not, would <iterate-column> be worthy of a JIRA?
>>>>>
>>>>> On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
>>>>>> The column widget is intended to be used for multi-column layout. It is
>>>>>> not a replacement for a grid widget.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 6/11/2015 1:21 PM, Christian Carlow wrote:
>>>>>>> <column-container> and <column> screen widgets seem to have been
>>>>>>> implemented based on the discussion and JIRAs, but creating a single
>>>>>>> table to contain a list doesn't seem supported for screens yet.  The
>>>>>>> following creates multiple tables for each <column-container>:
>>>>>>>
>>>>>>> <iterate-section>
>>>>>>> <column-container>
>>>>>>> <column>
>>>>>>> </column>
>>>>>>> </column-container>
>>>>>>> </iterate-section>
>>>>>>>
>>>>>>> Should something like the following be supported to implement single
>>>>>>> table functionality:
>>>>>>>
>>>>>>> <iterate-column list="listIt" style="basic-table" row-style="${groovy:
>>>>>>> if(rowCount%2==0) 'alternate-row'}">
>>>>>>> <column title="partyId">
>>>>>>> </column>
>>>>>>> <column title="partyName">
>>>>>>> </column>
>>>>>>> </iterate-column>
>>>>>>>
>>>>>>> Each iteration could create a row and row-style could be set using
>>>>>>> FlexibleStringExpander for groovy conditions.  <column-titles> would
>>>>>>> create 1 extra row at the top which may be empty.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
>>>>>>>> Thanks for the pointer Pierre.
>>>>>>>>
>>>>>>>> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
>>>>>>>> being supported by the form menu embedding functionality because html
>>>>>>>> forms cannot be nested.  It seems the grid or column functionality will
>>>>>>>> allow forms to be embedded in columns of table lists.  Therefore
>>>>>>>> OFBIZ-6404 probably isn't related since it implements a different
>>>>>>>> approach to menu/form embedding.
>>>>>>>>
>>>>>>>> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
>>>>>>>>> Various JIRA issues have been created, and several addressed/resolved. See
>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
>>>>>>>>> (does not link all).
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Pierre Smits
>>>>>>>>>
>>>>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>>>>> Services & Solutions for Cloud-
>>>>>>>>> Based Manufacturing, Professional
>>>>>>>>> Services and Retail & Trade
>>>>>>>>> http://www.orrtiz.com
>>>>>>>>>
>>>>>>>>> On Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <[hidden email]
>>>>>>>>>> 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 <
>>>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>>>>>> [hidden email]> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

[Christian Carlow-OFBizzer]

Thanks again for the feedback Adrian,

I updated OFBIZ-6404 patch so that form/grid embedded menu rendering is
treated as display instead of edit fields.  This causes the menus to be
rendered outside the edit form that gets created preventing violation of
html standard conformance.  

Extra logic was also added to handle menus of type hidden form so that
the row itemIndex is appended to the end of the id, otherwise duplicate
ids get rendered preventing the link javascript submissions from
triggering.  This seemed like a hack possibly handled better another
way.

OFBIZ-6501 and OFBIZ-6502 have been created to support embedding of
screens and forms/grids within grids based on OFBIZ-6404 menu embedding.
The same rowItem index id appending logic will probably need to be
included with patches for those issues but the implementation will
likely be more complex since grids may contain grids may contain grids
and each row itemIndex will have to be appended until the last row is
reached.

On Sun, 2015-06-14 at 10:12 -0700, Adrian Crum wrote:

> Keep in mind that menu items are rendered as forms for a reason - to
> fight XSS attacks. So, whatever solution you have in mind should not
> change that behavior.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 6/14/2015 10:05 AM, Christian Carlow wrote:
> > Thanks Adrian and sorry for the misunderstanding, you are right grids
> > are rendered as tables.
> >
> > The embedded menu rendering functionality provided by Nicolas in
> > OFBIZ-6404 needs to be modified so that menus are rendered outside of
> > any forms that may be created for grid row submissions.  As of right now
> > menus behave like edit fields and trigger the creation of an html form
> > element wrapper.
> >
> > I will patch OFBIZ-6404 so that menus always get rendered outside of row
> > edit forms in case of link-type="hidden-form".  Then I will implement
> > screen and form/grid embedding in a similar manner.
> >
> > Thanks again for your help.
> >
> > On Sun, 2015-06-14 at 09:12 -0700, Adrian Crum wrote:
> >> I thought a grid is rendered as a <table> element, I was not aware that
> >> it is rendered as a <form> element.
> >>
> >> Grids do not support including screens. That feature was suggested
> >> before, and it would be a nice one to have. Actually, it would be nice
> >> if grid and form widgets worked more like the screen widget - with
> >> sections that can be controlled by conditional elements.
> >>
> >> Adrian Crum
> >> Sandglass Software
> >> www.sandglass-software.com
> >>
> >> On 6/14/2015 3:03 AM, Christian Carlow wrote:
> >>> Thanks for the feedback Adrian.
> >>>
> >>> I check commit logs and see the grid widget additions back in January
> >>> that you recommended using for OFBIZ-6402 which I did.
> >>>
> >>> But grids don't appear to support embedding of screens.  Is this
> >>> something that is intended to be added later?
> >>>
> >>> If so, the difficulty is how to handle embedding of screens containing
> >>> forms when grid itself is already rendered as an html form element which
> >>> doesn't allow embedding of other form elements.
> >>>
> >>> This problem is demonstrated by OFBIZ-6404 where Nicolas added support
> >>> for menu embedding which only works if menu links are not rendered as
> >>> hidden forms.  Whenever the embedded menus are rendered as hidden forms
> >>> the links no longer work.
> >>>
> >>> I found no grid widget JIRAs and therefore don't know how to proceed to
> >>> support screen widget embedding within a table list.
> >>>
> >>> I started implementing <iterate-table> based on <iterate-section> but
> >>> with <column> as the child elements as an alternate way to generate a
> >>> table list than with grid.  This delivered the functionality I needed
> >>> but still needs improvements that seem redundantly supported by the grid
> >>> widget already, such as support for even and odd row coloring, column
> >>> titles etc.
> >>>
> >>> I'm trying to get some feedback as soon as possible so that I can make a
> >>> decision to continue on with the enhancements to <iterate-table> or to
> >>> abondon the <iterate-table> functionality already started and instead
> >>> pursue implementing screen embedding support for <grid>.
> >>>
> >>> For example:
> >>> <iterate-table entry="partyMap" list="partyMaps"
> >>> odd-row-style="alt-row">
> >>> <column title="${uiLabelMap.partyId}">
> >>> <label text="${partyMap.partyId}"
> >>> </column>
> >>> <column title="${uiLabelMap.partyAddress}">
> >>> <include-screen name="ViewPostalAddress"
> >>> location="component://party/widget/PartyScreens.xml"/>
> >>> </column>
> >>> </iterate-table>
> >>>
> >>> On Thu, 2015-06-11 at 23:10 -0700, Adrian Crum wrote:
> >>>> The grid widget is implemented. Please check the commit logs.
> >>>>
> >>>> The column widget is not intended to implement a grid. It is intended to
> >>>> be used for multi-column layout of screens (like newspaper columns).
> >>>>
> >>>> Adrian Crum
> >>>> Sandglass Software
> >>>> www.sandglass-software.com
> >>>>
> >>>> On 6/11/2015 2:57 PM, Christian Carlow wrote:
> >>>>> Adrian,
> >>>>>
> >>>>> So grid widget isn't implemented yet?
> >>>>>
> >>>>> Is there a JIRA for it?
> >>>>>
> >>>>> Would my proposal for <iterate-column> conflict with it's
> >>>>> implementation?
> >>>>>
> >>>>> If not, would <iterate-column> be worthy of a JIRA?
> >>>>>
> >>>>> On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
> >>>>>> The column widget is intended to be used for multi-column layout. It is
> >>>>>> not a replacement for a grid widget.
> >>>>>>
> >>>>>> Adrian Crum
> >>>>>> Sandglass Software
> >>>>>> www.sandglass-software.com
> >>>>>>
> >>>>>> On 6/11/2015 1:21 PM, Christian Carlow wrote:
> >>>>>>> <column-container> and <column> screen widgets seem to have been
> >>>>>>> implemented based on the discussion and JIRAs, but creating a single
> >>>>>>> table to contain a list doesn't seem supported for screens yet.  The
> >>>>>>> following creates multiple tables for each <column-container>:
> >>>>>>>
> >>>>>>> <iterate-section>
> >>>>>>> <column-container>
> >>>>>>> <column>
> >>>>>>> </column>
> >>>>>>> </column-container>
> >>>>>>> </iterate-section>
> >>>>>>>
> >>>>>>> Should something like the following be supported to implement single
> >>>>>>> table functionality:
> >>>>>>>
> >>>>>>> <iterate-column list="listIt" style="basic-table" row-style="${groovy:
> >>>>>>> if(rowCount%2==0) 'alternate-row'}">
> >>>>>>> <column title="partyId">
> >>>>>>> </column>
> >>>>>>> <column title="partyName">
> >>>>>>> </column>
> >>>>>>> </iterate-column>
> >>>>>>>
> >>>>>>> Each iteration could create a row and row-style could be set using
> >>>>>>> FlexibleStringExpander for groovy conditions.  <column-titles> would
> >>>>>>> create 1 extra row at the top which may be empty.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
> >>>>>>>> Thanks for the pointer Pierre.
> >>>>>>>>
> >>>>>>>> I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
> >>>>>>>> being supported by the form menu embedding functionality because html
> >>>>>>>> forms cannot be nested.  It seems the grid or column functionality will
> >>>>>>>> allow forms to be embedded in columns of table lists.  Therefore
> >>>>>>>> OFBIZ-6404 probably isn't related since it implements a different
> >>>>>>>> approach to menu/form embedding.
> >>>>>>>>
> >>>>>>>> On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
> >>>>>>>>> Various JIRA issues have been created, and several addressed/resolved. See
> >>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
> >>>>>>>>> (does not link all).
> >>>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>>>>
> >>>>>>>>> Pierre Smits
> >>>>>>>>>
> >>>>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
> >>>>>>>>> Services & Solutions for Cloud-
> >>>>>>>>> Based Manufacturing, Professional
> >>>>>>>>> Services and Retail & Trade
> >>>>>>>>> http://www.orrtiz.com
> >>>>>>>>>
> >>>>>>>>> On Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <[hidden email]
> >>>>>>>>>> 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 <
> >>>>>>>>>>> [hidden email]> 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 <
> >>>>>>>>>>>>> [hidden email]> 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 <
> >>>>>>>>>>>>>>> [hidden email]> 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
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
> >

[Jacques Le Roux]

Le 09/02/2015 à 11:21, Jacques Le Roux a écrit :

> Le 06/02/2015 17:27, Ron Wheeler a écrit : If there are a lot of required issues, then make it a community project to release it and get it done.
>>>>
>>>> If it is not clear about the state of a release branch, then have a meeting and make a decision.
>>>> Either it is
>>>> a) still under development and unstable or
>>>> b) it is a release candidate and only a defined and agreed upon set of bugs will be fixed before it is released and other low priority bugs and
>>>> backports will get done in the next minor release. If a new critical bug is found after it is declared a RC, then the team gets to decide if it
>>>> is included and adds it to the priority list or defers it.
>>>> If it is deferred, add a note in the release notes that an important bug is not fixed in the release but is or will be available as a patch to
>>>> the version in the trunk or development branch.
>>>>
>>>> This is not rocket science and if it done properly, in an organized way, it will be clear to Adrian and everyone how any backporting or bug
>>>> fixing should be done.
>>>
>>> Wait, we have already a rule about that. Yours are maybe not rocket science but are too complicated IMO.
>>>
>>
>> Do you have a link to the desription of the rule?
>
> No but you can create it in the wiki using what I wrote below

Done

https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=7766050&selectedPageVersions=42&selectedPageVersions=41

Jacques