You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by James Yong <ja...@apache.org> on 2020/05/15 16:08:07 UTC
Re: Chapter two: Rules to dynamize screen
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 <gi...@nereide.fr> 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
>
>
>
Re: Chapter two: Rules to dynamize screen
Posted by Gil Portenseigne <gi...@nereide.fr>.
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 <gi...@nereide.fr> 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
> >
> >
> >
Re: Chapter two: Rules to dynamize screen
Posted by Pierre Smits <pi...@apache.org>.
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 <ja...@apache.org> 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 <gi...@nereide.fr>
> 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
> >
> >
> >
>
Re: Chapter two: Rules to dynamize screen
Posted by Olivier Heintz <ho...@ofbizextra.org>.
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 <gi...@nereide.fr> 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
>>
>>
>>