Chapter two: Rules to dynamize screen

[Gil Portenseigne]

Hello !

In previous thread we focused on the process of how to define a dynamic
workflow that raises some questions.

Let's go back to our principles: we have to find simple things, limit
the possibilities (do little but good) and remember that on the
backoffice it's end-users who are focused on specific tasks.

To make it simple, implement screen dynamism that will generate
alterations of the dom, to limit side effects, we establish the
following principles:
  * We can only ask for an update of the area known by the calling
    element.

Knowing that the element of coherence in the screen engine is the
screen itself, we can refine this rule on the following basis
  * An element triggering a screen update, can only update elements
    present within the screen where it belongs.

Why did we made this choice? We will see it below, but the goal is
always to make writing easier for the developer by avoiding him to
wonder what is the value of the area to be refreshed.

If for various reasons we need to update an area outside the screen
where the call is located, it is better to ask for a global refresh of
the page. (Always simpler for the developer)

Another point to aim for simplicity, which zone to update?
We can identify several actions:
 * I'm on an item and I want to see related items data
 * I'm on an item and I want to refresh that item data

The first case is a defined relation, I will refresh this area with
this screen, area that will be generally determined by the decorator.
Then, we will talk about the so-called embedded screens: "embedded
screen".

The second case is about updating oneself following some sort of
procedure, I have to refresh myself. Nothing is best than "knowing it
yourself".

It was needed to implement an optimization to facilitate the application
of these principles. The idea is that in most cases, the developer
doesn't have to think about which zone he needs to specify to display
his data.

In order to apply the operation in a homogeneous way, we added new
structuring decorators in the common-theme with dedicated zone
identifiers allowing each implementation to exploit the refresh.

For example, for a detail screen of an entity (e.g. product categories),
we use a "DetailScreenDecorator" decorator. The main refresh area
"Associated Objects Details" is the main dynamic area of the screen.
We are going to identify precise areas so that each theme can be used in
knowledge:
    * breadcrumb: to display how we see the path to an entity
    * summary: to display a quick information on this entity
    * action: different actions available to this entity
    * navigation: links or other element who help user to navigate on
      the entity relation
    * detail: to display a relation

In our searchn once the list of needs is done, we have exploited the
areas for our theme as follows:


   +-----------------------------------------------------+
   | Catalog -> Category  (BreadCrumb)                   |
   | +-------------------------------------------------+ |
   | |                                   +------------+| |
   | |                                   | Quick Menu || |
   | |                                   +------------+| |
   | |                                                 | |
   | |              Category Summary                   | |
   | |                                                 | |
   | +-------------------------------------------------+ |
   |                                                     |
   | +-------------------------------------------------+ |
   | |Tab Menu | menu1 | menu2 | menu3                 | |
   | |-------------------------------------------------| |
   | |  <div id="detailArea">                          | |
   | |                                                 | |
   | |          Associated Objects Details             | |
   | |                                                 | |
   | |                                                 | |
   | |                                                 | |
   | |                                                 | |
   | +-------------------------------------------------+ |
   +-----------------------------------------------------+


The decorator will set a variable "detailArea" in the context of this
screen, which contains the id of the div to refresh to present a new
screen (products of the category for example).

The positioning of this type of variable facilitates the constraint on
the developer to refresh an area of the screen, if he wants to code the
Tab menu in a simplified way.

Also we are speaking about technical decorator, because we think that it
is necessary to add business decorators implementing those, facilitating
the recovery of information from the main object that is processed.

But we will discuss this in another mail Chapter 3 : promoting decorator
usage

Best Regards,

Leila, Nicolas and Gil

[James Yong-2]

Hi Gil,

Sorry for the late reply.
I agree that button actions should be decoupled from forms.
Shall we continue with Part 3?

Regards,
James

On 2020/01/10 17:58:59, Gil Portenseigne <[hidden email]> wrote:

> Hello !
>
> In previous thread we focused on the process of how to define a dynamic
> workflow that raises some questions.
>
> Let's go back to our principles: we have to find simple things, limit
> the possibilities (do little but good) and remember that on the
> backoffice it's end-users who are focused on specific tasks.
>
> To make it simple, implement screen dynamism that will generate
> alterations of the dom, to limit side effects, we establish the
> following principles:
>   * We can only ask for an update of the area known by the calling
>     element.
>
> Knowing that the element of coherence in the screen engine is the
> screen itself, we can refine this rule on the following basis
>   * An element triggering a screen update, can only update elements
>     present within the screen where it belongs.
>
> Why did we made this choice? We will see it below, but the goal is
> always to make writing easier for the developer by avoiding him to
> wonder what is the value of the area to be refreshed.
>
> If for various reasons we need to update an area outside the screen
> where the call is located, it is better to ask for a global refresh of
> the page. (Always simpler for the developer)
>
> Another point to aim for simplicity, which zone to update?
> We can identify several actions:
>  * I'm on an item and I want to see related items data
>  * I'm on an item and I want to refresh that item data
>
> The first case is a defined relation, I will refresh this area with
> this screen, area that will be generally determined by the decorator.
> Then, we will talk about the so-called embedded screens: "embedded
> screen".
>
> The second case is about updating oneself following some sort of
> procedure, I have to refresh myself. Nothing is best than "knowing it
> yourself".
>
> It was needed to implement an optimization to facilitate the application
> of these principles. The idea is that in most cases, the developer
> doesn't have to think about which zone he needs to specify to display
> his data.
>
> In order to apply the operation in a homogeneous way, we added new
> structuring decorators in the common-theme with dedicated zone
> identifiers allowing each implementation to exploit the refresh.
>
> For example, for a detail screen of an entity (e.g. product categories),
> we use a "DetailScreenDecorator" decorator. The main refresh area
> "Associated Objects Details" is the main dynamic area of the screen.
> We are going to identify precise areas so that each theme can be used in
> knowledge:
>     * breadcrumb: to display how we see the path to an entity
>     * summary: to display a quick information on this entity
>     * action: different actions available to this entity
>     * navigation: links or other element who help user to navigate on
>       the entity relation
>     * detail: to display a relation
>
> In our searchn once the list of needs is done, we have exploited the
> areas for our theme as follows:
>
>
>    +-----------------------------------------------------+
>    | Catalog -> Category  (BreadCrumb)                   |
>    | +-------------------------------------------------+ |
>    | |                                   +------------+| |
>    | |                                   | Quick Menu || |
>    | |                                   +------------+| |
>    | |                                                 | |
>    | |              Category Summary                   | |
>    | |                                                 | |
>    | +-------------------------------------------------+ |
>    |                                                     |
>    | +-------------------------------------------------+ |
>    | |Tab Menu | menu1 | menu2 | menu3                 | |
>    | |-------------------------------------------------| |
>    | |  <div id="detailArea">                          | |
>    | |                                                 | |
>    | |          Associated Objects Details             | |
>    | |                                                 | |
>    | |                                                 | |
>    | |                                                 | |
>    | |                                                 | |
>    | +-------------------------------------------------+ |
>    +-----------------------------------------------------+
>
>
> The decorator will set a variable "detailArea" in the context of this
> screen, which contains the id of the div to refresh to present a new
> screen (products of the category for example).
>
> The positioning of this type of variable facilitates the constraint on
> the developer to refresh an area of the screen, if he wants to code the
> Tab menu in a simplified way.
>
> Also we are speaking about technical decorator, because we think that it
> is necessary to add business decorators implementing those, facilitating
> the recovery of information from the main object that is processed.
>
> But we will discuss this in another mail Chapter 3 : promoting decorator
> usage
>
> Best Regards,
>
> Leila, Nicolas and Gil
>
>
>

[Pierre Smits-3]

HI Gil,
In your posting your mentioned: In previous thread

Can you provide a link to that thread?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Fri, May 15, 2020 at 6:08 PM James Yong <[hidden email]> wrote:

> Hi Gil,
>
> Sorry for the late reply.
> I agree that button actions should be decoupled from forms.
> Shall we continue with Part 3?
>
> Regards,
> James
>
> On 2020/01/10 17:58:59, Gil Portenseigne <[hidden email]>
> wrote:
> > Hello !
> >
> > In previous thread we focused on the process of how to define a dynamic
> > workflow that raises some questions.
> >
> > Let's go back to our principles: we have to find simple things, limit
> > the possibilities (do little but good) and remember that on the
> > backoffice it's end-users who are focused on specific tasks.
> >
> > To make it simple, implement screen dynamism that will generate
> > alterations of the dom, to limit side effects, we establish the
> > following principles:
> >   * We can only ask for an update of the area known by the calling
> >     element.
> >
> > Knowing that the element of coherence in the screen engine is the
> > screen itself, we can refine this rule on the following basis
> >   * An element triggering a screen update, can only update elements
> >     present within the screen where it belongs.
> >
> > Why did we made this choice? We will see it below, but the goal is
> > always to make writing easier for the developer by avoiding him to
> > wonder what is the value of the area to be refreshed.
> >
> > If for various reasons we need to update an area outside the screen
> > where the call is located, it is better to ask for a global refresh of
> > the page. (Always simpler for the developer)
> >
> > Another point to aim for simplicity, which zone to update?
> > We can identify several actions:
> >  * I'm on an item and I want to see related items data
> >  * I'm on an item and I want to refresh that item data
> >
> > The first case is a defined relation, I will refresh this area with
> > this screen, area that will be generally determined by the decorator.
> > Then, we will talk about the so-called embedded screens: "embedded
> > screen".
> >
> > The second case is about updating oneself following some sort of
> > procedure, I have to refresh myself. Nothing is best than "knowing it
> > yourself".
> >
> > It was needed to implement an optimization to facilitate the application
> > of these principles. The idea is that in most cases, the developer
> > doesn't have to think about which zone he needs to specify to display
> > his data.
> >
> > In order to apply the operation in a homogeneous way, we added new
> > structuring decorators in the common-theme with dedicated zone
> > identifiers allowing each implementation to exploit the refresh.
> >
> > For example, for a detail screen of an entity (e.g. product categories),
> > we use a "DetailScreenDecorator" decorator. The main refresh area
> > "Associated Objects Details" is the main dynamic area of the screen.
> > We are going to identify precise areas so that each theme can be used in
> > knowledge:
> >     * breadcrumb: to display how we see the path to an entity
> >     * summary: to display a quick information on this entity
> >     * action: different actions available to this entity
> >     * navigation: links or other element who help user to navigate on
> >       the entity relation
> >     * detail: to display a relation
> >
> > In our searchn once the list of needs is done, we have exploited the
> > areas for our theme as follows:
> >
> >
> >    +-----------------------------------------------------+
> >    | Catalog -> Category  (BreadCrumb)                   |
> >    | +-------------------------------------------------+ |
> >    | |                                   +------------+| |
> >    | |                                   | Quick Menu || |
> >    | |                                   +------------+| |
> >    | |                                                 | |
> >    | |              Category Summary                   | |
> >    | |                                                 | |
> >    | +-------------------------------------------------+ |
> >    |                                                     |
> >    | +-------------------------------------------------+ |
> >    | |Tab Menu | menu1 | menu2 | menu3                 | |
> >    | |-------------------------------------------------| |
> >    | |  <div id="detailArea">                          | |
> >    | |                                                 | |
> >    | |          Associated Objects Details             | |
> >    | |                                                 | |
> >    | |                                                 | |
> >    | |                                                 | |
> >    | |                                                 | |
> >    | +-------------------------------------------------+ |
> >    +-----------------------------------------------------+
> >
> >
> > The decorator will set a variable "detailArea" in the context of this
> > screen, which contains the id of the div to refresh to present a new
> > screen (products of the category for example).
> >
> > The positioning of this type of variable facilitates the constraint on
> > the developer to refresh an area of the screen, if he wants to code the
> > Tab menu in a simplified way.
> >
> > Also we are speaking about technical decorator, because we think that it
> > is necessary to add business decorators implementing those, facilitating
> > the recovery of information from the main object that is processed.
> >
> > But we will discuss this in another mail Chapter 3 : promoting decorator
> > usage
> >
> > Best Regards,
> >
> > Leila, Nicolas and Gil
> >
> >
> >
>

[Olivier.heintz]

Hi,

After gil remarks and test with the POC-Vue.js

We are now working with two new "action" usable by link - hyperlink
 * set-area
 * set-watcher
and in container, we have added attribute watcher-name, and using auto-update-target as target

set-area is used to update a containerId, and, most of the time, uses only for included containerId
set-watcher put some "parameters" in a watcher-name

when whatcher-name change, all containerId which watch it, use their auto-update-target as target and watcher-name content as parameters to update the
container content.

Hoping that this solution responds correctly to the problem raised

Le 15/05/2020 à 18:08, James Yong a écrit :

> Hi Gil,
>
> Sorry for the late reply.
> I agree that button actions should be decoupled from forms.
> Shall we continue with Part 3?
>
> Regards,
> James
>
> On 2020/01/10 17:58:59, Gil Portenseigne <[hidden email]> wrote:
>> Hello !
>>
>> In previous thread we focused on the process of how to define a dynamic
>> workflow that raises some questions.
>>
>> Let's go back to our principles: we have to find simple things, limit
>> the possibilities (do little but good) and remember that on the
>> backoffice it's end-users who are focused on specific tasks.
>>
>> To make it simple, implement screen dynamism that will generate
>> alterations of the dom, to limit side effects, we establish the
>> following principles:
>>   * We can only ask for an update of the area known by the calling
>>     element.
>>
>> Knowing that the element of coherence in the screen engine is the
>> screen itself, we can refine this rule on the following basis
>>   * An element triggering a screen update, can only update elements
>>     present within the screen where it belongs.
>>
>> Why did we made this choice? We will see it below, but the goal is
>> always to make writing easier for the developer by avoiding him to
>> wonder what is the value of the area to be refreshed.
>>
>> If for various reasons we need to update an area outside the screen
>> where the call is located, it is better to ask for a global refresh of
>> the page. (Always simpler for the developer)
>>
>> Another point to aim for simplicity, which zone to update?
>> We can identify several actions:
>>  * I'm on an item and I want to see related items data
>>  * I'm on an item and I want to refresh that item data
>>
>> The first case is a defined relation, I will refresh this area with
>> this screen, area that will be generally determined by the decorator.
>> Then, we will talk about the so-called embedded screens: "embedded
>> screen".
>>
>> The second case is about updating oneself following some sort of
>> procedure, I have to refresh myself. Nothing is best than "knowing it
>> yourself".
>>
>> It was needed to implement an optimization to facilitate the application
>> of these principles. The idea is that in most cases, the developer
>> doesn't have to think about which zone he needs to specify to display
>> his data.
>>
>> In order to apply the operation in a homogeneous way, we added new
>> structuring decorators in the common-theme with dedicated zone
>> identifiers allowing each implementation to exploit the refresh.
>>
>> For example, for a detail screen of an entity (e.g. product categories),
>> we use a "DetailScreenDecorator" decorator. The main refresh area
>> "Associated Objects Details" is the main dynamic area of the screen.
>> We are going to identify precise areas so that each theme can be used in
>> knowledge:
>>     * breadcrumb: to display how we see the path to an entity
>>     * summary: to display a quick information on this entity
>>     * action: different actions available to this entity
>>     * navigation: links or other element who help user to navigate on
>>       the entity relation
>>     * detail: to display a relation
>>
>> In our searchn once the list of needs is done, we have exploited the
>> areas for our theme as follows:
>>
>>
>>    +-----------------------------------------------------+
>>    | Catalog -> Category  (BreadCrumb)                   |
>>    | +-------------------------------------------------+ |
>>    | |                                   +------------+| |
>>    | |                                   | Quick Menu || |
>>    | |                                   +------------+| |
>>    | |                                                 | |
>>    | |              Category Summary                   | |
>>    | |                                                 | |
>>    | +-------------------------------------------------+ |
>>    |                                                     |
>>    | +-------------------------------------------------+ |
>>    | |Tab Menu | menu1 | menu2 | menu3                 | |
>>    | |-------------------------------------------------| |
>>    | |  <div id="detailArea">                          | |
>>    | |                                                 | |
>>    | |          Associated Objects Details             | |
>>    | |                                                 | |
>>    | |                                                 | |
>>    | |                                                 | |
>>    | |                                                 | |
>>    | +-------------------------------------------------+ |
>>    +-----------------------------------------------------+
>>
>>
>> The decorator will set a variable "detailArea" in the context of this
>> screen, which contains the id of the div to refresh to present a new
>> screen (products of the category for example).
>>
>> The positioning of this type of variable facilitates the constraint on
>> the developer to refresh an area of the screen, if he wants to code the
>> Tab menu in a simplified way.
>>
>> Also we are speaking about technical decorator, because we think that it
>> is necessary to add business decorators implementing those, facilitating
>> the recovery of information from the main object that is processed.
>>
>> But we will discuss this in another mail Chapter 3 : promoting decorator
>> usage
>>
>> Best Regards,
>>
>> Leila, Nicolas and Gil
>>
>>
>>

[Gil Portenseigne]

Hello James,

No worry i wasn't active due to the situation we are aware of...

I plan to get back into the subject in the coming weeks.

Regards,

Gil

On Fri, May 15, 2020 at 04:08:07PM -0000, James Yong wrote:

> Hi Gil,
>
> Sorry for the late reply.
> I agree that button actions should be decoupled from forms.
> Shall we continue with Part 3?
>
> Regards,
> James
>
> On 2020/01/10 17:58:59, Gil Portenseigne <[hidden email]> wrote:
> > Hello !
> >
> > In previous thread we focused on the process of how to define a dynamic
> > workflow that raises some questions.
> >
> > Let's go back to our principles: we have to find simple things, limit
> > the possibilities (do little but good) and remember that on the
> > backoffice it's end-users who are focused on specific tasks.
> >
> > To make it simple, implement screen dynamism that will generate
> > alterations of the dom, to limit side effects, we establish the
> > following principles:
> >   * We can only ask for an update of the area known by the calling
> >     element.
> >
> > Knowing that the element of coherence in the screen engine is the
> > screen itself, we can refine this rule on the following basis
> >   * An element triggering a screen update, can only update elements
> >     present within the screen where it belongs.
> >
> > Why did we made this choice? We will see it below, but the goal is
> > always to make writing easier for the developer by avoiding him to
> > wonder what is the value of the area to be refreshed.
> >
> > If for various reasons we need to update an area outside the screen
> > where the call is located, it is better to ask for a global refresh of
> > the page. (Always simpler for the developer)
> >
> > Another point to aim for simplicity, which zone to update?
> > We can identify several actions:
> >  * I'm on an item and I want to see related items data
> >  * I'm on an item and I want to refresh that item data
> >
> > The first case is a defined relation, I will refresh this area with
> > this screen, area that will be generally determined by the decorator.
> > Then, we will talk about the so-called embedded screens: "embedded
> > screen".
> >
> > The second case is about updating oneself following some sort of
> > procedure, I have to refresh myself. Nothing is best than "knowing it
> > yourself".
> >
> > It was needed to implement an optimization to facilitate the application
> > of these principles. The idea is that in most cases, the developer
> > doesn't have to think about which zone he needs to specify to display
> > his data.
> >
> > In order to apply the operation in a homogeneous way, we added new
> > structuring decorators in the common-theme with dedicated zone
> > identifiers allowing each implementation to exploit the refresh.
> >
> > For example, for a detail screen of an entity (e.g. product categories),
> > we use a "DetailScreenDecorator" decorator. The main refresh area
> > "Associated Objects Details" is the main dynamic area of the screen.
> > We are going to identify precise areas so that each theme can be used in
> > knowledge:
> >     * breadcrumb: to display how we see the path to an entity
> >     * summary: to display a quick information on this entity
> >     * action: different actions available to this entity
> >     * navigation: links or other element who help user to navigate on
> >       the entity relation
> >     * detail: to display a relation
> >
> > In our searchn once the list of needs is done, we have exploited the
> > areas for our theme as follows:
> >
> >
> >    +-----------------------------------------------------+
> >    | Catalog -> Category  (BreadCrumb)                   |
> >    | +-------------------------------------------------+ |
> >    | |                                   +------------+| |
> >    | |                                   | Quick Menu || |
> >    | |                                   +------------+| |
> >    | |                                                 | |
> >    | |              Category Summary                   | |
> >    | |                                                 | |
> >    | +-------------------------------------------------+ |
> >    |                                                     |
> >    | +-------------------------------------------------+ |
> >    | |Tab Menu | menu1 | menu2 | menu3                 | |
> >    | |-------------------------------------------------| |
> >    | |  <div id="detailArea">                          | |
> >    | |                                                 | |
> >    | |          Associated Objects Details             | |
> >    | |                                                 | |
> >    | |                                                 | |
> >    | |                                                 | |
> >    | |                                                 | |
> >    | +-------------------------------------------------+ |
> >    +-----------------------------------------------------+
> >
> >
> > The decorator will set a variable "detailArea" in the context of this
> > screen, which contains the id of the div to refresh to present a new
> > screen (products of the category for example).
> >
> > The positioning of this type of variable facilitates the constraint on
> > the developer to refresh an area of the screen, if he wants to code the
> > Tab menu in a simplified way.
> >
> > Also we are speaking about technical decorator, because we think that it
> > is necessary to add business decorators implementing those, facilitating
> > the recovery of information from the main object that is processed.
> >
> > But we will discuss this in another mail Chapter 3 : promoting decorator
> > usage
> >
> > Best Regards,
> >
> > Leila, Nicolas and Gil
> >
> >
> >