Widget Overhaul

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Widget Overhaul

Adrian Crum-3
Some time ago I started working on the screen widget thread safety.
There were many places in code where widget models were being modified
during rendering - resulting in unpredictable behavior, and in some
cases it resulted in users having access to data they shouldn't be able
to see.

While doing that work, I was overwhelmed by the quantity of source code.
The screen widget library was built using a lot of copy-and-paste -
instead of extracting and reusing common things. Scott started working
on reusing widget code, but that was just a small beginning.

In a recent commit, I continued his work and made some more things reusable.

Next, I would like to reorganize the source code folder structure. Here
is what I have pictured:

org/ofbiz/widget
   artifact (Artifact Info classes)
   cache (Widget cache classes)
   model (Widget models)
   renderer (Widget renderers)
     macro
     html
     xml

I think the simplified folder structure makes more sense and it will
make it easier to locate classes.

After that, I would like to add error checking code to the widget models
- similar to what I did in Mini-Language. Right now, errors in widget
XML are (sometimes) logged and widget parsing continues. If a developer
does something wrong, they will not know it unless they check the logs.
I would like to change the behavior so widget XML errors throw an
exception with a detailed error message that includes the XML file name
and line number where the error occurred. I believe this will benefit
developers by making it clear when they have done something wrong.

Finally, I would like to extract list functionality from the form widget
and create a new grid widget. So, instead of a form widget representing
a single data entry form OR a list, it will ONLY represent a single
form. If you want a list, you use the grid widget. Initially, this
change will be backwards-compatible - the XML parser will accept a
<form> element for both types and it will create the correct model based
on the type attribute.

Overall, my goal is to make screen widgets more developer-friendly, and
also to make it easier to innovate in the screen widget component.

After all of this work is completed, I would like to backport it to the
R14 branch.

Comments are welcome.


--
Adrian Crum
Sandglass Software
www.sandglass-software.com
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Pierre Smits
Hi Adrian,

I am inclined to say that any code improvement that removes quirkiness in
current code or unpredictable behaviour while at the same time helping
contributors to develop better solutions deserves a +1.

However I have some concerns regarding the approach you're following.

First, as we can expect that the quirkiness in current widget code is being
utilized in various places in the dependent components, refactoring the
widget code can lead to a multitude of issues regarding Screens and Forms
in those components. I truly hope this will be as bad as I fear.

Secondly, refactoring the widget code will have an impact on performance. I
am sure we all hope (and some will expect it to be so) it is a positive
effect, but we can't tell - at this moment in time - what it will be.

Given the two concerns I would rather have seen that the refactoring was
taking place in a separate development branch than in trunk. Having it done
that way we would have the opportunity to compare the performance aspects
of the refactored code against trunk (e.g. with Apache jMeter and such),
and if favourable have another argument to tell to the users of old
releases.

Also while having the refactoring taking place in the development branch,
we can not only isolate the aspects of my first concern (development branch
issues vs trunk issues), but we will be able to better explain what the
effects of the refactoring could be visavis (potential) issues of the users
of old versions considering upgrading.

Best regards,


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Jan 17, 2015 at 6:46 PM, Adrian Crum <
[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
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Adrian Crum-3
Comparisons can be done on any branch.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/17/2015 1:40 PM, Pierre Smits wrote:

> Hi Adrian,
>
> I am inclined to say that any code improvement that removes quirkiness in
> current code or unpredictable behaviour while at the same time helping
> contributors to develop better solutions deserves a +1.
>
> However I have some concerns regarding the approach you're following.
>
> First, as we can expect that the quirkiness in current widget code is being
> utilized in various places in the dependent components, refactoring the
> widget code can lead to a multitude of issues regarding Screens and Forms
> in those components. I truly hope this will be as bad as I fear.
>
> Secondly, refactoring the widget code will have an impact on performance. I
> am sure we all hope (and some will expect it to be so) it is a positive
> effect, but we can't tell - at this moment in time - what it will be.
>
> Given the two concerns I would rather have seen that the refactoring was
> taking place in a separate development branch than in trunk. Having it done
> that way we would have the opportunity to compare the performance aspects
> of the refactored code against trunk (e.g. with Apache jMeter and such),
> and if favourable have another argument to tell to the users of old
> releases.
>
> Also while having the refactoring taking place in the development branch,
> we can not only isolate the aspects of my first concern (development branch
> issues vs trunk issues), but we will be able to better explain what the
> effects of the refactoring could be visavis (potential) issues of the users
> of old versions considering upgrading.
>
> Best regards,
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sat, Jan 17, 2015 at 6:46 PM, Adrian Crum <
> [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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Pierre Smits
True.

But would you not like it that this refactoring isn't a factor when a
comparison between a release and trunk shows that trunk is performing worse
than a release?

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Jan 17, 2015 at 10:44 PM, Adrian Crum <
[hidden email]> wrote:

> Comparisons can be done on any branch.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/17/2015 1:40 PM, Pierre Smits wrote:
>
>> Hi Adrian,
>>
>> I am inclined to say that any code improvement that removes quirkiness in
>> current code or unpredictable behaviour while at the same time helping
>> contributors to develop better solutions deserves a +1.
>>
>> However I have some concerns regarding the approach you're following.
>>
>> First, as we can expect that the quirkiness in current widget code is
>> being
>> utilized in various places in the dependent components, refactoring the
>> widget code can lead to a multitude of issues regarding Screens and Forms
>> in those components. I truly hope this will be as bad as I fear.
>>
>> Secondly, refactoring the widget code will have an impact on performance.
>> I
>> am sure we all hope (and some will expect it to be so) it is a positive
>> effect, but we can't tell - at this moment in time - what it will be.
>>
>> Given the two concerns I would rather have seen that the refactoring was
>> taking place in a separate development branch than in trunk. Having it
>> done
>> that way we would have the opportunity to compare the performance aspects
>> of the refactored code against trunk (e.g. with Apache jMeter and such),
>> and if favourable have another argument to tell to the users of old
>> releases.
>>
>> Also while having the refactoring taking place in the development branch,
>> we can not only isolate the aspects of my first concern (development
>> branch
>> issues vs trunk issues), but we will be able to better explain what the
>> effects of the refactoring could be visavis (potential) issues of the
>> users
>> of old versions considering upgrading.
>>
>> Best regards,
>>
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Sat, Jan 17, 2015 at 6:46 PM, Adrian Crum <
>> [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
>>>
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Adrian Crum-3
I am not doing anything that affects performance, so I am not interested
in a comparison.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/17/2015 2:58 PM, Pierre Smits wrote:

> True.
>
> But would you not like it that this refactoring isn't a factor when a
> comparison between a release and trunk shows that trunk is performing worse
> than a release?
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sat, Jan 17, 2015 at 10:44 PM, Adrian Crum <
> [hidden email]> wrote:
>
>> Comparisons can be done on any branch.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/17/2015 1:40 PM, Pierre Smits wrote:
>>
>>> Hi Adrian,
>>>
>>> I am inclined to say that any code improvement that removes quirkiness in
>>> current code or unpredictable behaviour while at the same time helping
>>> contributors to develop better solutions deserves a +1.
>>>
>>> However I have some concerns regarding the approach you're following.
>>>
>>> First, as we can expect that the quirkiness in current widget code is
>>> being
>>> utilized in various places in the dependent components, refactoring the
>>> widget code can lead to a multitude of issues regarding Screens and Forms
>>> in those components. I truly hope this will be as bad as I fear.
>>>
>>> Secondly, refactoring the widget code will have an impact on performance.
>>> I
>>> am sure we all hope (and some will expect it to be so) it is a positive
>>> effect, but we can't tell - at this moment in time - what it will be.
>>>
>>> Given the two concerns I would rather have seen that the refactoring was
>>> taking place in a separate development branch than in trunk. Having it
>>> done
>>> that way we would have the opportunity to compare the performance aspects
>>> of the refactored code against trunk (e.g. with Apache jMeter and such),
>>> and if favourable have another argument to tell to the users of old
>>> releases.
>>>
>>> Also while having the refactoring taking place in the development branch,
>>> we can not only isolate the aspects of my first concern (development
>>> branch
>>> issues vs trunk issues), but we will be able to better explain what the
>>> effects of the refactoring could be visavis (potential) issues of the
>>> users
>>> of old versions considering upgrading.
>>>
>>> Best regards,
>>>
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Sat, Jan 17, 2015 at 6:46 PM, Adrian Crum <
>>> [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
>>>>
>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Gavin Mabie-2
In reply to this post by Adrian Crum-3
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
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Adrian Crum-3
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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Gavin Mabie-2
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
>>>
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Adrian Crum-3
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
>>>>
>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Gavin Mabie-2
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
>>>>>
>>>>>
>>>>>
>>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Pierre Smits
Hi Adrian,

Would it not be a good thing to have all the linking definition to be
refactored to one single definiton?

Currently we have:

   - link
   - hyperlink
   - sub-hyperlink

It seems to me that they are intended to deliver the same functionality,
but are applied differently per application area:

   1. link -> menu, screen - but with different behaviour between the two,
   e.g. ajax-window doesn't work in a menu
   2. hyperlink -> forms, commonly used to have a link associated to a field
   3. sub-hyperlink -> forms, commonly used in a display entity associated
   to a field

Best regards,


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <[hidden email]> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Adrian Crum-3
I did that already - in the schema and in code. There is a common link
type, then the various widgets extend it to add their specific attributes.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/23/2015 1:45 AM, Pierre Smits wrote:

> Hi Adrian,
>
> Would it not be a good thing to have all the linking definition to be
> refactored to one single definiton?
>
> Currently we have:
>
>     - link
>     - hyperlink
>     - sub-hyperlink
>
> It seems to me that they are intended to deliver the same functionality,
> but are applied differently per application area:
>
>     1. link -> menu, screen - but with different behaviour between the two,
>     e.g. ajax-window doesn't work in a menu
>     2. hyperlink -> forms, commonly used to have a link associated to a field
>     3. sub-hyperlink -> forms, commonly used in a display entity associated
>     to a field
>
> Best regards,
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <[hidden email]> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Pierre Smits
Yes, I thought so too.

But when I use link in a Sreen.xml, like example below:

<link link-type="ajax-window"  target=
"newaction?partyId=${parameters.partyId}" width="1000" height="400" text=
"${uiLabelMap.CommonCreateNew}" style="buttontext create"/>
I get a popup window.

Whereas when I use the same in a menu-item, like:

 <menu-item name="newaction" title="${uiLabelMap.SEPASetBankAttributes}">
     <link link-type="ajax-window" target="nAttributeLayer" title=
"${uiLabelMap.CommonCreateNew}" width="1000" height="600">
        <parameter param-name="partyId" from-field="partyId"/>
    </link>
</menu-item>


it doesn't open the screen in a popup wind, in stead it renders the new
screen in the browser window.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum <
[hidden email]> wrote:

> I did that already - in the schema and in code. There is a common link
> type, then the various widgets extend it to add their specific attributes.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/23/2015 1:45 AM, Pierre Smits wrote:
>
>> Hi Adrian,
>>
>> Would it not be a good thing to have all the linking definition to be
>> refactored to one single definiton?
>>
>> Currently we have:
>>
>>     - link
>>     - hyperlink
>>     - sub-hyperlink
>>
>> It seems to me that they are intended to deliver the same functionality,
>> but are applied differently per application area:
>>
>>     1. link -> menu, screen - but with different behaviour between the
>> two,
>>     e.g. ajax-window doesn't work in a menu
>>     2. hyperlink -> forms, commonly used to have a link associated to a
>> field
>>     3. sub-hyperlink -> forms, commonly used in a display entity
>> associated
>>     to a field
>>
>> Best regards,
>>
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <[hidden email]> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Pierre Smits
So I can use ajax-window in a screen, but then must I resort to a complex
setup in a section with regards to conditon settings to get an ajax window.

Or when using a menu and menu item to utilise conditions, I must resort to
calling a javascript to get an ajax window.


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Jan 23, 2015 at 4:01 PM, Pierre Smits <[hidden email]>
wrote:

> Yes, I thought so too.
>
> But when I use link in a Sreen.xml, like example below:
>
> <link link-type="ajax-window"  target=
> "newaction?partyId=${parameters.partyId}" width="1000" height="400" text=
> "${uiLabelMap.CommonCreateNew}" style="buttontext create"/>
> I get a popup window.
>
> Whereas when I use the same in a menu-item, like:
>
>  <menu-item name="newaction" title="${uiLabelMap.SEPASetBankAttributes}">
>      <link link-type="ajax-window" target="nAttributeLayer" title=
> "${uiLabelMap.CommonCreateNew}" width="1000" height="600">
>         <parameter param-name="partyId" from-field="partyId"/>
>     </link>
> </menu-item>
>
>
> it doesn't open the screen in a popup wind, in stead it renders the new
> screen in the browser window.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum <
> [hidden email]> wrote:
>
>> I did that already - in the schema and in code. There is a common link
>> type, then the various widgets extend it to add their specific attributes.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/23/2015 1:45 AM, Pierre Smits wrote:
>>
>>> Hi Adrian,
>>>
>>> Would it not be a good thing to have all the linking definition to be
>>> refactored to one single definiton?
>>>
>>> Currently we have:
>>>
>>>     - link
>>>     - hyperlink
>>>     - sub-hyperlink
>>>
>>> It seems to me that they are intended to deliver the same functionality,
>>> but are applied differently per application area:
>>>
>>>     1. link -> menu, screen - but with different behaviour between the
>>> two,
>>>     e.g. ajax-window doesn't work in a menu
>>>     2. hyperlink -> forms, commonly used to have a link associated to a
>>> field
>>>     3. sub-hyperlink -> forms, commonly used in a display entity
>>> associated
>>>     to a field
>>>
>>> Best regards,
>>>
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <[hidden email]>
>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Adrian Crum-3
In reply to this post by Pierre Smits
Right. The renderers need to be updated to render links consistently. So
far, I have avoided touching the renderers. I will work on those later
if I have time. Meanwhile, feel free to create a patch and I will apply it.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/23/2015 7:01 AM, Pierre Smits wrote:

> Yes, I thought so too.
>
> But when I use link in a Sreen.xml, like example below:
>
> <link link-type="ajax-window"  target=
> "newaction?partyId=${parameters.partyId}" width="1000" height="400" text=
> "${uiLabelMap.CommonCreateNew}" style="buttontext create"/>
> I get a popup window.
>
> Whereas when I use the same in a menu-item, like:
>
>   <menu-item name="newaction" title="${uiLabelMap.SEPASetBankAttributes}">
>       <link link-type="ajax-window" target="nAttributeLayer" title=
> "${uiLabelMap.CommonCreateNew}" width="1000" height="600">
>          <parameter param-name="partyId" from-field="partyId"/>
>      </link>
> </menu-item>
>
>
> it doesn't open the screen in a popup wind, in stead it renders the new
> screen in the browser window.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum <
> [hidden email]> wrote:
>
>> I did that already - in the schema and in code. There is a common link
>> type, then the various widgets extend it to add their specific attributes.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/23/2015 1:45 AM, Pierre Smits wrote:
>>
>>> Hi Adrian,
>>>
>>> Would it not be a good thing to have all the linking definition to be
>>> refactored to one single definiton?
>>>
>>> Currently we have:
>>>
>>>      - link
>>>      - hyperlink
>>>      - sub-hyperlink
>>>
>>> It seems to me that they are intended to deliver the same functionality,
>>> but are applied differently per application area:
>>>
>>>      1. link -> menu, screen - but with different behaviour between the
>>> two,
>>>      e.g. ajax-window doesn't work in a menu
>>>      2. hyperlink -> forms, commonly used to have a link associated to a
>>> field
>>>      3. sub-hyperlink -> forms, commonly used in a display entity
>>> associated
>>>      to a field
>>>
>>> Best regards,
>>>
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <[hidden email]> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Pierre Smits
Ahh. Ok.

Thanks for the insights.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum <
[hidden email]> wrote:

> Right. The renderers need to be updated to render links consistently. So
> far, I have avoided touching the renderers. I will work on those later if I
> have time. Meanwhile, feel free to create a patch and I will apply it.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/23/2015 7:01 AM, Pierre Smits wrote:
>
>> Yes, I thought so too.
>>
>> But when I use link in a Sreen.xml, like example below:
>>
>> <link link-type="ajax-window"  target=
>> "newaction?partyId=${parameters.partyId}" width="1000" height="400" text=
>> "${uiLabelMap.CommonCreateNew}" style="buttontext create"/>
>> I get a popup window.
>>
>> Whereas when I use the same in a menu-item, like:
>>
>>   <menu-item name="newaction" title="${uiLabelMap.
>> SEPASetBankAttributes}">
>>       <link link-type="ajax-window" target="nAttributeLayer" title=
>> "${uiLabelMap.CommonCreateNew}" width="1000" height="600">
>>          <parameter param-name="partyId" from-field="partyId"/>
>>      </link>
>> </menu-item>
>>
>>
>> it doesn't open the screen in a popup wind, in stead it renders the new
>> screen in the browser window.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum <
>> [hidden email]> wrote:
>>
>>  I did that already - in the schema and in code. There is a common link
>>> type, then the various widgets extend it to add their specific
>>> attributes.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 1/23/2015 1:45 AM, Pierre Smits wrote:
>>>
>>>  Hi Adrian,
>>>>
>>>> Would it not be a good thing to have all the linking definition to be
>>>> refactored to one single definiton?
>>>>
>>>> Currently we have:
>>>>
>>>>      - link
>>>>      - hyperlink
>>>>      - sub-hyperlink
>>>>
>>>> It seems to me that they are intended to deliver the same functionality,
>>>> but are applied differently per application area:
>>>>
>>>>      1. link -> menu, screen - but with different behaviour between the
>>>> two,
>>>>      e.g. ajax-window doesn't work in a menu
>>>>      2. hyperlink -> forms, commonly used to have a link associated to a
>>>> field
>>>>      3. sub-hyperlink -> forms, commonly used in a display entity
>>>> associated
>>>>      to a field
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <[hidden email]>
>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Pierre Smits
I have created the placeholder for now:
https://issues.apache.org/jira/browse/OFBIZ-6034

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Jan 23, 2015 at 4:24 PM, Pierre Smits <[hidden email]>
wrote:

> Ahh. Ok.
>
> Thanks for the insights.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum <
> [hidden email]> wrote:
>
>> Right. The renderers need to be updated to render links consistently. So
>> far, I have avoided touching the renderers. I will work on those later if I
>> have time. Meanwhile, feel free to create a patch and I will apply it.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/23/2015 7:01 AM, Pierre Smits wrote:
>>
>>> Yes, I thought so too.
>>>
>>> But when I use link in a Sreen.xml, like example below:
>>>
>>> <link link-type="ajax-window"  target=
>>> "newaction?partyId=${parameters.partyId}" width="1000" height="400"
>>> text=
>>> "${uiLabelMap.CommonCreateNew}" style="buttontext create"/>
>>> I get a popup window.
>>>
>>> Whereas when I use the same in a menu-item, like:
>>>
>>>   <menu-item name="newaction" title="${uiLabelMap.
>>> SEPASetBankAttributes}">
>>>       <link link-type="ajax-window" target="nAttributeLayer" title=
>>> "${uiLabelMap.CommonCreateNew}" width="1000" height="600">
>>>          <parameter param-name="partyId" from-field="partyId"/>
>>>      </link>
>>> </menu-item>
>>>
>>>
>>> it doesn't open the screen in a popup wind, in stead it renders the new
>>> screen in the browser window.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum <
>>> [hidden email]> wrote:
>>>
>>>  I did that already - in the schema and in code. There is a common link
>>>> type, then the various widgets extend it to add their specific
>>>> attributes.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 1/23/2015 1:45 AM, Pierre Smits wrote:
>>>>
>>>>  Hi Adrian,
>>>>>
>>>>> Would it not be a good thing to have all the linking definition to be
>>>>> refactored to one single definiton?
>>>>>
>>>>> Currently we have:
>>>>>
>>>>>      - link
>>>>>      - hyperlink
>>>>>      - sub-hyperlink
>>>>>
>>>>> It seems to me that they are intended to deliver the same
>>>>> functionality,
>>>>> but are applied differently per application area:
>>>>>
>>>>>      1. link -> menu, screen - but with different behaviour between the
>>>>> two,
>>>>>      e.g. ajax-window doesn't work in a menu
>>>>>      2. hyperlink -> forms, commonly used to have a link associated to
>>>>> a
>>>>> field
>>>>>      3. sub-hyperlink -> forms, commonly used in a display entity
>>>>> associated
>>>>>      to a field
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>> On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <[hidden email]>
>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Pierre Smits
Adrian,

Could you update http://ofbiz.apache.org/dtds/ so that the underlaying xsd
files reflect the recent changes?

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Jan 23, 2015 at 5:01 PM, Pierre Smits <[hidden email]>
wrote:

> I have created the placeholder for now:
> https://issues.apache.org/jira/browse/OFBIZ-6034
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Fri, Jan 23, 2015 at 4:24 PM, Pierre Smits <[hidden email]>
> wrote:
>
>> Ahh. Ok.
>>
>> Thanks for the insights.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum <
>> [hidden email]> wrote:
>>
>>> Right. The renderers need to be updated to render links consistently. So
>>> far, I have avoided touching the renderers. I will work on those later if I
>>> have time. Meanwhile, feel free to create a patch and I will apply it.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 1/23/2015 7:01 AM, Pierre Smits wrote:
>>>
>>>> Yes, I thought so too.
>>>>
>>>> But when I use link in a Sreen.xml, like example below:
>>>>
>>>> <link link-type="ajax-window"  target=
>>>> "newaction?partyId=${parameters.partyId}" width="1000" height="400"
>>>> text=
>>>> "${uiLabelMap.CommonCreateNew}" style="buttontext create"/>
>>>> I get a popup window.
>>>>
>>>> Whereas when I use the same in a menu-item, like:
>>>>
>>>>   <menu-item name="newaction" title="${uiLabelMap.
>>>> SEPASetBankAttributes}">
>>>>       <link link-type="ajax-window" target="nAttributeLayer" title=
>>>> "${uiLabelMap.CommonCreateNew}" width="1000" height="600">
>>>>          <parameter param-name="partyId" from-field="partyId"/>
>>>>      </link>
>>>> </menu-item>
>>>>
>>>>
>>>> it doesn't open the screen in a popup wind, in stead it renders the new
>>>> screen in the browser window.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum <
>>>> [hidden email]> wrote:
>>>>
>>>>  I did that already - in the schema and in code. There is a common link
>>>>> type, then the various widgets extend it to add their specific
>>>>> attributes.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 1/23/2015 1:45 AM, Pierre Smits wrote:
>>>>>
>>>>>  Hi Adrian,
>>>>>>
>>>>>> Would it not be a good thing to have all the linking definition to be
>>>>>> refactored to one single definiton?
>>>>>>
>>>>>> Currently we have:
>>>>>>
>>>>>>      - link
>>>>>>      - hyperlink
>>>>>>      - sub-hyperlink
>>>>>>
>>>>>> It seems to me that they are intended to deliver the same
>>>>>> functionality,
>>>>>> but are applied differently per application area:
>>>>>>
>>>>>>      1. link -> menu, screen - but with different behaviour between
>>>>>> the
>>>>>> two,
>>>>>>      e.g. ajax-window doesn't work in a menu
>>>>>>      2. hyperlink -> forms, commonly used to have a link associated
>>>>>> to a
>>>>>> field
>>>>>>      3. sub-hyperlink -> forms, commonly used in a display entity
>>>>>> associated
>>>>>>      to a field
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>>
>>>>>> Pierre Smits
>>>>>>
>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>>
>>>>>> Services & Solutions for Cloud-
>>>>>> Based Manufacturing, Professional
>>>>>> Services and Retail & Trade
>>>>>> http://www.orrtiz.com
>>>>>>
>>>>>> On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <[hidden email]>
>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Adrian Crum-3
Done.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/23/2015 12:45 PM, Pierre Smits wrote:

> Adrian,
>
> Could you update http://ofbiz.apache.org/dtds/ so that the underlaying xsd
> files reflect the recent changes?
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Fri, Jan 23, 2015 at 5:01 PM, Pierre Smits <[hidden email]>
> wrote:
>
>> I have created the placeholder for now:
>> https://issues.apache.org/jira/browse/OFBIZ-6034
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Fri, Jan 23, 2015 at 4:24 PM, Pierre Smits <[hidden email]>
>> wrote:
>>
>>> Ahh. Ok.
>>>
>>> Thanks for the insights.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum <
>>> [hidden email]> wrote:
>>>
>>>> Right. The renderers need to be updated to render links consistently. So
>>>> far, I have avoided touching the renderers. I will work on those later if I
>>>> have time. Meanwhile, feel free to create a patch and I will apply it.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 1/23/2015 7:01 AM, Pierre Smits wrote:
>>>>
>>>>> Yes, I thought so too.
>>>>>
>>>>> But when I use link in a Sreen.xml, like example below:
>>>>>
>>>>> <link link-type="ajax-window"  target=
>>>>> "newaction?partyId=${parameters.partyId}" width="1000" height="400"
>>>>> text=
>>>>> "${uiLabelMap.CommonCreateNew}" style="buttontext create"/>
>>>>> I get a popup window.
>>>>>
>>>>> Whereas when I use the same in a menu-item, like:
>>>>>
>>>>>    <menu-item name="newaction" title="${uiLabelMap.
>>>>> SEPASetBankAttributes}">
>>>>>        <link link-type="ajax-window" target="nAttributeLayer" title=
>>>>> "${uiLabelMap.CommonCreateNew}" width="1000" height="600">
>>>>>           <parameter param-name="partyId" from-field="partyId"/>
>>>>>       </link>
>>>>> </menu-item>
>>>>>
>>>>>
>>>>> it doesn't open the screen in a popup wind, in stead it renders the new
>>>>> screen in the browser window.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>> On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>   I did that already - in the schema and in code. There is a common link
>>>>>> type, then the various widgets extend it to add their specific
>>>>>> attributes.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 1/23/2015 1:45 AM, Pierre Smits wrote:
>>>>>>
>>>>>>   Hi Adrian,
>>>>>>>
>>>>>>> Would it not be a good thing to have all the linking definition to be
>>>>>>> refactored to one single definiton?
>>>>>>>
>>>>>>> Currently we have:
>>>>>>>
>>>>>>>       - link
>>>>>>>       - hyperlink
>>>>>>>       - sub-hyperlink
>>>>>>>
>>>>>>> It seems to me that they are intended to deliver the same
>>>>>>> functionality,
>>>>>>> but are applied differently per application area:
>>>>>>>
>>>>>>>       1. link -> menu, screen - but with different behaviour between
>>>>>>> the
>>>>>>> two,
>>>>>>>       e.g. ajax-window doesn't work in a menu
>>>>>>>       2. hyperlink -> forms, commonly used to have a link associated
>>>>>>> to a
>>>>>>> field
>>>>>>>       3. sub-hyperlink -> forms, commonly used in a display entity
>>>>>>> associated
>>>>>>>       to a field
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>>>
>>>>>>> Services & Solutions for Cloud-
>>>>>>> Based Manufacturing, Professional
>>>>>>> Services and Retail & Trade
>>>>>>> http://www.orrtiz.com
>>>>>>>
>>>>>>> On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <[hidden email]>
>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Widget Overhaul

Pierre Smits
Thanks!

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Jan 23, 2015 at 11:17 PM, Adrian Crum <
[hidden email]> wrote:

> Done.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/23/2015 12:45 PM, Pierre Smits wrote:
>
>> Adrian,
>>
>> Could you update http://ofbiz.apache.org/dtds/ so that the underlaying
>> xsd
>> files reflect the recent changes?
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Fri, Jan 23, 2015 at 5:01 PM, Pierre Smits <[hidden email]>
>> wrote:
>>
>>  I have created the placeholder for now:
>>> https://issues.apache.org/jira/browse/OFBIZ-6034
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Fri, Jan 23, 2015 at 4:24 PM, Pierre Smits <[hidden email]>
>>> wrote:
>>>
>>>  Ahh. Ok.
>>>>
>>>> Thanks for the insights.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Fri, Jan 23, 2015 at 4:18 PM, Adrian Crum <
>>>> [hidden email]> wrote:
>>>>
>>>>  Right. The renderers need to be updated to render links consistently.
>>>>> So
>>>>> far, I have avoided touching the renderers. I will work on those later
>>>>> if I
>>>>> have time. Meanwhile, feel free to create a patch and I will apply it.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 1/23/2015 7:01 AM, Pierre Smits wrote:
>>>>>
>>>>>  Yes, I thought so too.
>>>>>>
>>>>>> But when I use link in a Sreen.xml, like example below:
>>>>>>
>>>>>> <link link-type="ajax-window"  target=
>>>>>> "newaction?partyId=${parameters.partyId}" width="1000" height="400"
>>>>>> text=
>>>>>> "${uiLabelMap.CommonCreateNew}" style="buttontext create"/>
>>>>>> I get a popup window.
>>>>>>
>>>>>> Whereas when I use the same in a menu-item, like:
>>>>>>
>>>>>>    <menu-item name="newaction" title="${uiLabelMap.
>>>>>> SEPASetBankAttributes}">
>>>>>>        <link link-type="ajax-window" target="nAttributeLayer" title=
>>>>>> "${uiLabelMap.CommonCreateNew}" width="1000" height="600">
>>>>>>           <parameter param-name="partyId" from-field="partyId"/>
>>>>>>       </link>
>>>>>> </menu-item>
>>>>>>
>>>>>>
>>>>>> it doesn't open the screen in a popup wind, in stead it renders the
>>>>>> new
>>>>>> screen in the browser window.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Pierre Smits
>>>>>>
>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>> Services & Solutions for Cloud-
>>>>>> Based Manufacturing, Professional
>>>>>> Services and Retail & Trade
>>>>>> http://www.orrtiz.com
>>>>>>
>>>>>> On Fri, Jan 23, 2015 at 3:31 PM, Adrian Crum <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>   I did that already - in the schema and in code. There is a common
>>>>>> link
>>>>>>
>>>>>>> type, then the various widgets extend it to add their specific
>>>>>>> attributes.
>>>>>>>
>>>>>>> Adrian Crum
>>>>>>> Sandglass Software
>>>>>>> www.sandglass-software.com
>>>>>>>
>>>>>>> On 1/23/2015 1:45 AM, Pierre Smits wrote:
>>>>>>>
>>>>>>>   Hi Adrian,
>>>>>>>
>>>>>>>>
>>>>>>>> Would it not be a good thing to have all the linking definition to
>>>>>>>> be
>>>>>>>> refactored to one single definiton?
>>>>>>>>
>>>>>>>> Currently we have:
>>>>>>>>
>>>>>>>>       - link
>>>>>>>>       - hyperlink
>>>>>>>>       - sub-hyperlink
>>>>>>>>
>>>>>>>> It seems to me that they are intended to deliver the same
>>>>>>>> functionality,
>>>>>>>> but are applied differently per application area:
>>>>>>>>
>>>>>>>>       1. link -> menu, screen - but with different behaviour between
>>>>>>>> the
>>>>>>>> two,
>>>>>>>>       e.g. ajax-window doesn't work in a menu
>>>>>>>>       2. hyperlink -> forms, commonly used to have a link associated
>>>>>>>> to a
>>>>>>>> field
>>>>>>>>       3. sub-hyperlink -> forms, commonly used in a display entity
>>>>>>>> associated
>>>>>>>>       to a field
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>>
>>>>>>>> Pierre Smits
>>>>>>>>
>>>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>>>>
>>>>>>>> Services & Solutions for Cloud-
>>>>>>>> Based Manufacturing, Professional
>>>>>>>> Services and Retail & Trade
>>>>>>>> http://www.orrtiz.com
>>>>>>>>
>>>>>>>> On Mon, Jan 19, 2015 at 7:30 AM, Gavin Mabie <[hidden email]>
>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>
123