I thought a grid is rendered as a <table> element, I was not aware that
it is rendered as a <form> element.
Grids do not support including screens. That feature was suggested
before, and it would be a nice one to have. Actually, it would be nice
if grid and form widgets worked more like the screen widget - with
sections that can be controlled by conditional elements.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 6/14/2015 3:03 AM, Christian Carlow wrote:
Thanks for the feedback Adrian.
I check commit logs and see the grid widget additions back in January
that you recommended using for OFBIZ-6402 which I did.
But grids don't appear to support embedding of screens. Is this
something that is intended to be added later?
If so, the difficulty is how to handle embedding of screens containing
forms when grid itself is already rendered as an html form element which
doesn't allow embedding of other form elements.
This problem is demonstrated by OFBIZ-6404 where Nicolas added support
for menu embedding which only works if menu links are not rendered as
hidden forms. Whenever the embedded menus are rendered as hidden forms
the links no longer work.
I found no grid widget JIRAs and therefore don't know how to proceed to
support screen widget embedding within a table list.
I started implementing <iterate-table> based on <iterate-section> but
with <column> as the child elements as an alternate way to generate a
table list than with grid. This delivered the functionality I needed
but still needs improvements that seem redundantly supported by the grid
widget already, such as support for even and odd row coloring, column
titles etc.
I'm trying to get some feedback as soon as possible so that I can make a
decision to continue on with the enhancements to <iterate-table> or to
abondon the <iterate-table> functionality already started and instead
pursue implementing screen embedding support for <grid>.
For example:
<iterate-table entry="partyMap" list="partyMaps"
odd-row-style="alt-row">
<column title="${uiLabelMap.partyId}">
<label text="${partyMap.partyId}"
</column>
<column title="${uiLabelMap.partyAddress}">
<include-screen name="ViewPostalAddress"
location="component://party/widget/PartyScreens.xml"/>
</column>
</iterate-table>
On Thu, 2015-06-11 at 23:10 -0700, Adrian Crum wrote:
The grid widget is implemented. Please check the commit logs.
The column widget is not intended to implement a grid. It is intended to
be used for multi-column layout of screens (like newspaper columns).
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 6/11/2015 2:57 PM, Christian Carlow wrote:
Adrian,
So grid widget isn't implemented yet?
Is there a JIRA for it?
Would my proposal for <iterate-column> conflict with it's
implementation?
If not, would <iterate-column> be worthy of a JIRA?
On Thu, 2015-06-11 at 14:18 -0700, Adrian Crum wrote:
The column widget is intended to be used for multi-column layout. It is
not a replacement for a grid widget.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 6/11/2015 1:21 PM, Christian Carlow wrote:
<column-container> and <column> screen widgets seem to have been
implemented based on the discussion and JIRAs, but creating a single
table to contain a list doesn't seem supported for screens yet. The
following creates multiple tables for each <column-container>:
<iterate-section>
<column-container>
<column>
</column>
</column-container>
</iterate-section>
Should something like the following be supported to implement single
table functionality:
<iterate-column list="listIt" style="basic-table" row-style="${groovy:
if(rowCount%2==0) 'alternate-row'}">
<column title="partyId">
</column>
<column title="partyName">
</column>
</iterate-column>
Each iteration could create a row and row-style could be set using
FlexibleStringExpander for groovy conditions. <column-titles> would
create 1 extra row at the top which may be empty.
On Sun, 2015-06-07 at 11:50 -0500, Christian Carlow wrote:
Thanks for the pointer Pierre.
I commented on OFBIZ-6404 about menus with link-type="hidden-form" not
being supported by the form menu embedding functionality because html
forms cannot be nested. It seems the grid or column functionality will
allow forms to be embedded in columns of table lists. Therefore
OFBIZ-6404 probably isn't related since it implements a different
approach to menu/form embedding.
On Sun, 2015-06-07 at 18:06 +0200, Pierre Smits wrote:
Various JIRA issues have been created, and several addressed/resolved. See
https://issues.apache.org/jira/browse/OFBIZ-6314 for a placeholder issue
(does not link all).
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Sun, Jun 7, 2015 at 5:56 PM, Christian Carlow <christian.car...@gmail.com
wrote:
What is the status of the grid widget enhancements discussed by Adrian
and Gavin in this thread? Can other widgets be embedded within grids
yet? Is Nicolas' enhancement allowing menus to be embedded as form
fields of OFBIZ-6404 related to this?
On Mon, 2015-01-19 at 08:30 +0200, Gavin Mabie wrote:
Yes. Cell/Column sizes in conjunction with screen media directives can
then be used to achieve responsive layouts.
On Mon, Jan 19, 2015 at 7:13 AM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
So, you're suggesting a grid widget would accept any screen widget
within
a cell? That could be done fairly easily.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/18/2015 8:49 PM, Gavin Mabie wrote:
With columns already existing, rendering them inside rows would
constitute
a grid.
On Sun, Jan 18, 2015 at 6:19 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
We have columns for that.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/17/2015 6:14 PM, Gavin Mabie wrote:
Hi Adrian
I like the grid idea. It will almost certainly simplify and
enhance UI
design. Furthermore, it will facilitate responsive design in
Ofbiz. I
agree that form widget should apply to forms. I would recommend
that we
create a table widget for multi-column lists instead of the proposed
grid
widget. My thinking is that the grid widget should be used as a
layout
widget on a level just beneath screens but higher than lower level
widgets
(screenlets/forms/tables/menus/trees). In other words a screen
contains
grids and grids contain lower level widgets. This pattern will
enable
us
to make Ofbiz truly responsive. What do you think?
Gavin
On Sat, Jan 17, 2015 at 7:46 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
Some time ago I started working on the screen widget thread
safety.
There
were many places in code where widget models were being modified
during
rendering - resulting in unpredictable behavior, and in some cases
it
resulted in users having access to data they shouldn't be able to
see.
While doing that work, I was overwhelmed by the quantity of source
code.
The screen widget library was built using a lot of copy-and-paste -
instead
of extracting and reusing common things. Scott started working on
reusing
widget code, but that was just a small beginning.
In a recent commit, I continued his work and made some more things
reusable.
Next, I would like to reorganize the source code folder structure.
Here
is
what I have pictured:
org/ofbiz/widget
artifact (Artifact Info classes)
cache (Widget cache classes)
model (Widget models)
renderer (Widget renderers)
macro
html
xml
I think the simplified folder structure makes more sense and it
will
make
it easier to locate classes.
After that, I would like to add error checking code to the widget
models
-
similar to what I did in Mini-Language. Right now, errors in
widget XML
are
(sometimes) logged and widget parsing continues. If a developer
does
something wrong, they will not know it unless they check the logs.
I
would
like to change the behavior so widget XML errors throw an exception
with
a
detailed error message that includes the XML file name and line
number
where the error occurred. I believe this will benefit developers by
making
it clear when they have done something wrong.
Finally, I would like to extract list functionality from the form
widget
and create a new grid widget. So, instead of a form widget
representing a
single data entry form OR a list, it will ONLY represent a single
form.
If
you want a list, you use the grid widget. Initially, this change
will
be
backwards-compatible - the XML parser will accept a <form> element
for
both
types and it will create the correct model based on the type
attribute.
Overall, my goal is to make screen widgets more
developer-friendly, and
also to make it easier to innovate in the screen widget component.
After all of this work is completed, I would like to backport it
to the
R14 branch.
Comments are welcome.
--
Adrian Crum
Sandglass Software
www.sandglass-software.com
