Re: Fwd: Re: What is OFBiz public API?

[Jacques Le Roux]

Thanks Mathieu,

It's quite clear to me now

Jacques

Le 11/01/2020 à 21:52, Mathieu Lirzin a écrit :

Hello Jacques,

Jacques Le Roux  writes:


Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit :

Michael Brohl  writes:


This project is not only about tech, it has a user base with serious
business running on base of OFBiz. This has always to be considered as
serious as good technical solutions should be considered. So we cannot
simply change things because single contributors like other technical
solutions better. We have to remain downwards compatible and manage
deprecation of features carefully.

First to clarify things, making evolutions in the framework is not about
developers changing arbitrary stuff, it is about structuring internals
in an understandeable way to enable correctness and the inclusion of new
features that satisfies evolving requirements.

Maybe you could clarify what you want to achieve. I have the feeling
that you have a long term view and the “component-load.xml change” is
only a step, right?

Yes I am/was working on the support of Jar distribution of OFBiz
allowing to separate the source code and compilation process of the
framework from the development of plugins. Basically it means
transforming OFBiz from a project template into a library to improve the
extensibility and reusability of both the framework and the plugins.

Moreover this work is contributing to the effort of facilitating the
deployment of OFBiz in production environments (in the continuity of
‘gradlew distTar’) by allowing the move of specific configuration out of
the source tree and deploying every resources inside the Jar.

I have described the rationale for this work in [1].


[...]

For the record, Without the ability to safely refactor a large subset of
the codebase that have the status of “implementation details”, I will
simply stop contributing to OFBiz because I don't have time for endless
discussions with people blaming my community work because their
extensions happen to rely on unspecified behavior.

For the current case, the most important question is to know if both
solutions could work at the same time, and if yes at which cost? Have
you an idea about that?

Sure we can keep both options which is the easy way to settle a
disagreement in the short term, I have allowed this in my last patch on
OFBIZ-11296 [2] by supporting both  and “component-load.xml”
at the same time with a priority on “component-load.xml”.

However to be able to continue the work of [1] it is important to remove
the usage of “component-load.xml” inside the framework.

[1] 
https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E
[2] 
https://issues.apache.org/jira/secure/attachment/12989898/12989898_OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch

Re: What is OFBiz public API?

[Mathieu Lirzin]

Hello Paul, Jacopo and Olivier,

Paul Foxworthy  writes:

> Being clearer about it would be a good thing.  There is still the
> potential that a change that seems simple and straightforward to one
> contributor is disruptive to others. And if it truly is disruptive, we
> should collaborate on what comes next. Are the benefits worth the
> disruption? Should there be some sort of deprecation, phase-out or
> backwards compatibility option? I can't clearly define what "big" is,
> but I know it when I see it.

IMO “We Should collaborate” is wishful thinking, because in practice
what happens most of the time is that only one person is doing the work
that he/she is proposing and the rest is doing +1 or -1. When someone
objects it often just means more burden for the person doing the work
because the person objecting will just add extra requirements.

Don't get me wrong, I find that situation normal because nobody is doing
a better job than someone who is motivated about it. Moreover people
with “ideas” but which are not responsible for implementing those tend
to advocate less practicable ideas.

It is just that I don't think we should expect the community to work
collectively better than the norm by relying on collaboration to be able
to get things done.

Jacopo Cappellato  writes:

> There will always be a tension between guaranteeing backward compatibility
> for the existing user base and the efforts to maintain our codebase,
> enhance/refactor/innovate it.
> Considering the peculiar nature of OFBiz, I don't think that trying to
> define the areas that are part of the "public API" and then guarantee
> backward compatibility only for them, will resolve this tension. In fact
> there may be cases in which the "public API" should change in a
> non-backward compatible way such as:
> * the cost of maintaining a backward compatible feature is too high for our
> community (or there is not enough interest in the active community in
> maintaining it)
> * the change is required to fix a flaw or a security vulnerability
> * some fundamental (and important to the community) architectural change
> may not be backward compatible
> * etc...

Specifying a public API does not mean necessarily preserving it. It just
mean knowing when a border is being crossed:

- The developer changing something that is part of that API
- The user using an undocumented mechanism that happen to be here.

> Apart from this, even the definition of "public API" for OFBiz is
> troublesome considering for example that potentially any OFBiz service can
> be used by "client" code and as a consequence in theory our community
> should never change the behavior (or remove) a service.

Ideally yes because the notion of services is about providing something
to others.  To reduce the compatibility cost it should be possible to
make “convenience” services that are only meant to be used locally by
other services, be implemented as a private/package level helper methods
instead of a service.

I don't have specific examples in mind but I am pretty sure that there
exist a lot of those.

> There are cases (like the one that triggered this conversation) that may
> involve some community discussion because it is difficult to figure out if
> the cost (in terms of pains for our users) is worth the gain (in terms of
> better/cleaner code): sometimes these discussions can be frustrating but if
> we all try to stay open (to the other point of view), positive, flexible,
> patient I am sure we will cope with them.

I agree that it is normal to spend some potentially long time discussing
the tradeoffs when considering a change that impact the public API
(whether it just adds a new feature or it breaks/deprecate existing
ones)

However knowing the boundaries between the public/private API is very
useful to understand each other and agree on the extent of those
tradeoffs.

For example in the current situation it happens that Michael is
considering “applications/component-load.xml” part of the implicit
public API¹ and as a consequence requires a community validation, a
deprecation period and a migration guides to be provided. When in the
same time I am considering it as an implementation detail that don't
need such extra work on my side.

Basically listening to each other in the context of an objection to a
change means putting all the burden on the framework developper which
either have to spend time convincing users that they should not use one
thing and migrate to another thing, or adding corner cases inside the
code to preverve the specific behavior expected by users.

Moreover even if the burden is all on the developer this still sucks
because it works only for users involved in the development (subscribed
to ML), but others will have to deal with their own unexpected breakage
without having the developer to help them.

Olivier Heintz  writes:

> 4) implementation detail or core choice, often, it's depend of point
> of view you use On ERP development / implementation there 

Re: Fwd: Re: What is OFBiz public API?

[Mathieu Lirzin]

Hello Jacques,

Jacques Le Roux  writes:

> Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit :
>>
>> Michael Brohl  writes:
>>
>>> This project is not only about tech, it has a user base with serious
>>> business running on base of OFBiz. This has always to be considered as
>>> serious as good technical solutions should be considered. So we cannot
>>> simply change things because single contributors like other technical
>>> solutions better. We have to remain downwards compatible and manage
>>> deprecation of features carefully.
>>
>> First to clarify things, making evolutions in the framework is not about
>> developers changing arbitrary stuff, it is about structuring internals
>> in an understandeable way to enable correctness and the inclusion of new
>> features that satisfies evolving requirements.
>
> Maybe you could clarify what you want to achieve. I have the feeling
> that you have a long term view and the “component-load.xml change” is
> only a step, right?

Yes I am/was working on the support of Jar distribution of OFBiz
allowing to separate the source code and compilation process of the
framework from the development of plugins. Basically it means
transforming OFBiz from a project template into a library to improve the
extensibility and reusability of both the framework and the plugins.

Moreover this work is contributing to the effort of facilitating the
deployment of OFBiz in production environments (in the continuity of
‘gradlew distTar’) by allowing the move of specific configuration out of
the source tree and deploying every resources inside the Jar.

I have described the rationale for this work in [1].

> [...]
>> For the record, Without the ability to safely refactor a large subset of
>> the codebase that have the status of “implementation details”, I will
>> simply stop contributing to OFBiz because I don't have time for endless
>> discussions with people blaming my community work because their
>> extensions happen to rely on unspecified behavior.
>
> For the current case, the most important question is to know if both
> solutions could work at the same time, and if yes at which cost? Have
> you an idea about that?

Sure we can keep both options which is the easy way to settle a
disagreement in the short term, I have allowed this in my last patch on
OFBIZ-11296 [2] by supporting both  and “component-load.xml”
at the same time with a priority on “component-load.xml”.

However to be able to continue the work of [1] it is important to remove
the usage of “component-load.xml” inside the framework.

[1] 
https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E
[2] 
https://issues.apache.org/jira/secure/attachment/12989898/12989898_OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Clarification about “removing component-load.xml feature” (was: What is OFBiz public API?)

[Mathieu Lirzin]

Hello,

Here are two clarifications about removing the “component-load.xml”
feature.

Michael Brohl  writes:

> Am 05.01.20 um 18:32 schrieb Mathieu Lirzin:
>
>> effectively optional (like the marketing example you brought) it should
>> eventually be moved in the official plugins if we actually want to
>> provides the capability for users to disable it. However users should
>
> Even it it would be a plugin, you still need a mechanism to
> enable/disable it by configuration.
>
> To my understanding, if we use depends-on exclusively for framework,
> applications and plugins, this would not be possible anymore.

It depends if you consider modifying the “ofbiz-component.xml” as
configuration or not. If yes there exists the “enabled” attribute of the
 element which provides a mechanism to disable a
component.

> Am 06.01.20 um 10:29 schrieb Samuel Trégouët:
>
>> 1. component-load.xml in plugin directory seems to be feature (nobody
>> discuss this point)
>
> That *might* be a misunderstanding (if Mathieu agrees on this
> point). My understanding was that he first implemented and committed
> the change for framework and applications (on Nov. 25).
>
> From his mail in dev [1] and also the issue title of [2] I understand
> that the component-load mechanism should be removed *everywhere*
> afterwards. The dev mail would not make sense otherwise because
> already committed the work at the time of writing (two weeks before)
> and he announces to go on if noone objects.
>
> I apologize if I missed a point here, maybe Mathieu can clarify this?

Even if I advocate for superseding “plugins/component-load.xml” with
, I recognize it as a feature (documented briefly in the
README).

You are correct that in [1] I did not mention that feature and focus on
the removal of “framework/base/component-load.xml” which is another
potential user-space configuration mechanism.  I could have spoken about
the “plugins/component-load.xml” feature too but at that time I thought
it was less likely to matter than “framework/base/component-load.xml”
because of the immaturity of the plugins mechanism and the long term
existence of “framework/base/component-load.xml”.

Does it clarify things?

>> [1]: 
>> https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E
>> [2]: 
>> https://lists.apache.org/thread.html/7eab3d2ae3bbeadb184b02f75f7b2b86263532485e88ecba4d4dc780%40%3Cdev.ofbiz.apache.org%3E


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Introduction

[Bright Efuet]

Hello everone My name is EFUET BRIGHT.  i am new to open source but love the 
Groovy Language. so i decided to join the APACHE OFBIZ project to widen my 
knowledge as far as open source is concern. I would also love to participate to 
Gsoc 2020. 

Re: [DISCUSSION] Make Back-Office screens dynamic

[James Yong]

Hi Jacques,

Points taken. 

Thanks,
James

On 2020/01/11 10:46:03, Jacques Le Roux  wrote: 
> Also jquery.x is not much maintained, last changes are from June 2015...
> 
> Le 11/01/2020 à 11:44, Jacques Le Roux a écrit :
> > Just noticed it needs Bower to install and at the moment Bowers says
> >
> >    "...psst! While Bower is maintained, we recommend using Yarn 
> >  and Webpack  or Parcel
> >     for front-end projects read how to migrate 
> > ! "
> >
> > And npm warns about it
> >
> > Jacques
> >
> >
> > Le 11/01/2020 à 10:32, Jacques Le Roux a écrit :
> >> I remember having read about MVVM years ago, quite interesting, thanks 
> >> James!
> >>
> >> Jacques
> >>
> >> Le 10/01/2020 à 16:50, James Yong a écrit :
> >>> Hi Gil,
> >>>
> >>> I wonder if this library helps for a start:
> >>> https://github.com/joshualjohnson/jquery.x
> >>>
> >>> Regards,
> >>> James
> >>>
> >>> On 2019/12/13 15:52:38, Gil Portenseigne  
> >>> wrote:
>  Chapter One: How to manage the updating area
> 
>  Hello,
> 
>  After different discussions already listed by Taher [1-9], Leila,
>  Nicolas and me tried another approach.
>  Instead of analyzing how to implement different functionalities offered
>  by modern js framework, we did analyzed how end user use, in general,
>  OFBiz and where we, as an integrator, waste more time to create a
>  screen.
> 
>  To help on this huge task, we set some basic rules :
>   * Work only on screens supported by the theme, defined mainly in xml
>   * This concerns only screens used for back-office applications,
>     oriented to manage data
>   * A developer does not have to know all of js language (or other)
>     but can concentrate on the process/view with the end user to
>     manage a data
> 
> 
>  After a first brainstorm, we have identified three major cases :
>   1. Navigation and data display
>   2. View event result (data modification, calculation service, ...)
>   3. Update an area to refresh data (after data modification)
> 
>  Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff
>  will be simple to add), we concentrate our attention on case 3.
> 
>  To update an area, we follow this pattern
> 
>   1. We start from a context that display different information
> 
>   2. That context display a submit form, use a link or another
>   mechanism to call an OFBiz event
> 
>   3. After receiving the event return, we refresh the desired area
>   with parameters that can come from origin context or from event
>   return.
> 
> 
>  Currently with the screen widget, we can use within a form the element
>  ``.
> 
>  The problem with this use, is that your form needs to know the origin
>  context, to identify what are the areas to update and what are the
>  target to use for the refresh.
> 
>  So your form needs to know where it comes from, what information need to
>  be updated in OFBiz and what will be updated after.
> 
>  This increases complexity for the developer in the way that current form
>  implementation manages :
>     * the data and target to communicate with the server
>     * the behaviour (refreshment) to apply when receiving server response.
> 
>  Example :
>     target="createPartyRole">
>   
>   ...
>     area-id="PartyRoles_area"
>  area-target="PartyRolesCustom">
>     from-field="parameters.partyId"/>
>   
>   
> 
>  If you want to reuse the same form, you need to create another screen
>  with a new form to redefine the on-event-update-area (for instance
>  create a PartyRole).
> 
>  We change the thinking, because since it is the starting context that
>  better knows itself, it's the starting context that will realize the
>  updating operation. The starting context is the screen/menu that call
>  this form.
> 
>  In general a form is contained in a screen (classic) that is called
>  through a link. So we move the idea on this link :
> 
>   
>     from-field="customerParty.partyId"/>
>     area-id="xxx">
>     from-field="customerParty.partyId"/>
>   
>   
> 
>   And the form :
> 
>     target="createPartyRole">
>      
>      ...
>   
> 
>   With this logic you can define a new usage of createPartyRole
>   without redefining a form just :
> 
>   

Re: [DISCUSSION] Make Back-Office screens dynamic

[Jacques Le Roux]

Also jquery.x is not much maintained, last changes are from June 2015...

Le 11/01/2020 à 11:44, Jacques Le Roux a écrit :

Just noticed it needs Bower to install and at the moment Bowers says

   "...psst! While Bower is maintained, we recommend using Yarn  
and Webpack  or Parcel
    for front-end projects read how to migrate 
! "

And npm warns about it

Jacques


Le 11/01/2020 à 10:32, Jacques Le Roux a écrit :

I remember having read about MVVM years ago, quite interesting, thanks James!

Jacques

Le 10/01/2020 à 16:50, James Yong a écrit :

Hi Gil,

I wonder if this library helps for a start:
https://github.com/joshualjohnson/jquery.x

Regards,
James

On 2019/12/13 15:52:38, Gil Portenseigne  wrote:

Chapter One: How to manage the updating area

Hello,

After different discussions already listed by Taher [1-9], Leila,
Nicolas and me tried another approach.
Instead of analyzing how to implement different functionalities offered
by modern js framework, we did analyzed how end user use, in general,
OFBiz and where we, as an integrator, waste more time to create a
screen.

To help on this huge task, we set some basic rules :
 * Work only on screens supported by the theme, defined mainly in xml
 * This concerns only screens used for back-office applications,
   oriented to manage data
 * A developer does not have to know all of js language (or other)
   but can concentrate on the process/view with the end user to
   manage a data


After a first brainstorm, we have identified three major cases :
 1. Navigation and data display
 2. View event result (data modification, calculation service, ...)
 3. Update an area to refresh data (after data modification)

Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff
will be simple to add), we concentrate our attention on case 3.

To update an area, we follow this pattern

 1. We start from a context that display different information

 2. That context display a submit form, use a link or another
 mechanism to call an OFBiz event

 3. After receiving the event return, we refresh the desired area
 with parameters that can come from origin context or from event
 return.


Currently with the screen widget, we can use within a form the element
``.

The problem with this use, is that your form needs to know the origin
context, to identify what are the areas to update and what are the
target to use for the refresh.

So your form needs to know where it comes from, what information need to
be updated in OFBiz and what will be updated after.

This increases complexity for the developer in the way that current form
implementation manages :
   * the data and target to communicate with the server
   * the behaviour (refreshment) to apply when receiving server response.

Example :
 
 
 ...
 
 
 
 

If you want to reuse the same form, you need to create another screen
with a new form to redefine the on-event-update-area (for instance
create a PartyRole).

We change the thinking, because since it is the starting context that
better knows itself, it's the starting context that will realize the
updating operation. The starting context is the screen/menu that call
this form.

In general a form is contained in a screen (classic) that is called
through a link. So we move the idea on this link :

 
 
 
 
 
 

 And the form :

 
    
    ...
 

 With this logic you can define a new usage of createPartyRole
 without redefining a form just :

 
 
 
 
 
 
 

After some use we identified as pro and con feedback :
 * updating form is reusable and contains only code related to the
   form action
 * link being in origin context, the developer knows where he is and
   where he wants to go
 * Menu oriented management offers a quick vision on how the screen will 
works

 * update-area seems to be a too technical name
 * we always have to manage area to update manually
 * too many areas to update become a headache and not only for the developer

We did not explain how we have done it, to try to focus the discussion
on the principles.

It would be a pleasure to have some criticism of this approach, and we
would try, in a second chapter to introduce other concepts that appeared
after the screens were made more dynamic and others to lowers the
identified cons.

Thanks,

The Néréide Team

[1] https://s.apache.org/rf94
[2] https://s.apache.org/g5zr
[3] https://s.apache.org/XpBO
[4] https://s.apache.org/YIL1
[5] https://s.apache.org/836D
[6] 

Re: [DISCUSSION] Make Back-Office screens dynamic

[Jacques Le Roux]

Just noticed it needs Bower to install and at the moment Bowers says

   "...psst! While Bower is maintained, we recommend using Yarn  
and Webpack  or Parcel
    for front-end projects read how to migrate 
! "

And npm warns about it

Jacques


Le 11/01/2020 à 10:32, Jacques Le Roux a écrit :

I remember having read about MVVM years ago, quite interesting, thanks James!

Jacques

Le 10/01/2020 à 16:50, James Yong a écrit :

Hi Gil,

I wonder if this library helps for a start:
https://github.com/joshualjohnson/jquery.x

Regards,
James

On 2019/12/13 15:52:38, Gil Portenseigne  wrote:

Chapter One: How to manage the updating area

Hello,

After different discussions already listed by Taher [1-9], Leila,
Nicolas and me tried another approach.
Instead of analyzing how to implement different functionalities offered
by modern js framework, we did analyzed how end user use, in general,
OFBiz and where we, as an integrator, waste more time to create a
screen.

To help on this huge task, we set some basic rules :
 * Work only on screens supported by the theme, defined mainly in xml
 * This concerns only screens used for back-office applications,
   oriented to manage data
 * A developer does not have to know all of js language (or other)
   but can concentrate on the process/view with the end user to
   manage a data


After a first brainstorm, we have identified three major cases :
 1. Navigation and data display
 2. View event result (data modification, calculation service, ...)
 3. Update an area to refresh data (after data modification)

Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff
will be simple to add), we concentrate our attention on case 3.

To update an area, we follow this pattern

 1. We start from a context that display different information

 2. That context display a submit form, use a link or another
 mechanism to call an OFBiz event

 3. After receiving the event return, we refresh the desired area
 with parameters that can come from origin context or from event
 return.


Currently with the screen widget, we can use within a form the element
``.

The problem with this use, is that your form needs to know the origin
context, to identify what are the areas to update and what are the
target to use for the refresh.

So your form needs to know where it comes from, what information need to
be updated in OFBiz and what will be updated after.

This increases complexity for the developer in the way that current form
implementation manages :
   * the data and target to communicate with the server
   * the behaviour (refreshment) to apply when receiving server response.

Example :
 
 
 ...
 
 
 
 

If you want to reuse the same form, you need to create another screen
with a new form to redefine the on-event-update-area (for instance
create a PartyRole).

We change the thinking, because since it is the starting context that
better knows itself, it's the starting context that will realize the
updating operation. The starting context is the screen/menu that call
this form.

In general a form is contained in a screen (classic) that is called
through a link. So we move the idea on this link :

 
 
 
 
 
 

 And the form :

 
    
    ...
 

 With this logic you can define a new usage of createPartyRole
 without redefining a form just :

 
 
 
 
 
 
 

After some use we identified as pro and con feedback :
 * updating form is reusable and contains only code related to the
   form action
 * link being in origin context, the developer knows where he is and
   where he wants to go
 * Menu oriented management offers a quick vision on how the screen will 
works

 * update-area seems to be a too technical name
 * we always have to manage area to update manually
 * too many areas to update become a headache and not only for the developer

We did not explain how we have done it, to try to focus the discussion
on the principles.

It would be a pleasure to have some criticism of this approach, and we
would try, in a second chapter to introduce other concepts that appeared
after the screens were made more dynamic and others to lowers the
identified cons.

Thanks,

The Néréide Team

[1] https://s.apache.org/rf94
[2] https://s.apache.org/g5zr
[3] https://s.apache.org/XpBO
[4] https://s.apache.org/YIL1
[5] https://s.apache.org/836D
[6] https://s.apache.org/DhyB
[7] https://s.apache.org/Lv9E
[8] https://s.apache.org/zKIo
[9] https://s.apache.org/D6jx

Re: [DISCUSSION] Make Back-Office screens dynamic

[Jacques Le Roux]

I remember having read about MVVM years ago, quite interesting, thanks James!

Jacques

Le 10/01/2020 à 16:50, James Yong a écrit :

Hi Gil,

I wonder if this library helps for a start:
https://github.com/joshualjohnson/jquery.x

Regards,
James

On 2019/12/13 15:52:38, Gil Portenseigne  wrote:

Chapter One: How to manage the updating area

Hello,

After different discussions already listed by Taher [1-9], Leila,
Nicolas and me tried another approach.
Instead of analyzing how to implement different functionalities offered
by modern js framework, we did analyzed how end user use, in general,
OFBiz and where we, as an integrator, waste more time to create a
screen.

To help on this huge task, we set some basic rules :
 * Work only on screens supported by the theme, defined mainly in xml
 * This concerns only screens used for back-office applications,
   oriented to manage data
 * A developer does not have to know all of js language (or other)
   but can concentrate on the process/view with the end user to
   manage a data


After a first brainstorm, we have identified three major cases :
 1. Navigation and data display
 2. View event result (data modification, calculation service, ...)
 3. Update an area to refresh data (after data modification)

Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff
will be simple to add), we concentrate our attention on case 3.

To update an area, we follow this pattern

 1. We start from a context that display different information

 2. That context display a submit form, use a link or another
 mechanism to call an OFBiz event

 3. After receiving the event return, we refresh the desired area
 with parameters that can come from origin context or from event
 return.


Currently with the screen widget, we can use within a form the element
``.

The problem with this use, is that your form needs to know the origin
context, to identify what are the areas to update and what are the
target to use for the refresh.

So your form needs to know where it comes from, what information need to
be updated in OFBiz and what will be updated after.

This increases complexity for the developer in the way that current form
implementation manages :
   * the data and target to communicate with the server
   * the behaviour (refreshment) to apply when receiving server response.

Example :
 
 
 ...
 
 
 
 

If you want to reuse the same form, you need to create another screen
with a new form to redefine the on-event-update-area (for instance
create a PartyRole).

We change the thinking, because since it is the starting context that
better knows itself, it's the starting context that will realize the
updating operation. The starting context is the screen/menu that call
this form.

In general a form is contained in a screen (classic) that is called
through a link. So we move the idea on this link :

 
 
 
 
 
 

 And the form :

 

...
 

 With this logic you can define a new usage of createPartyRole
 without redefining a form just :

 
 
 
 
 
 
 

After some use we identified as pro and con feedback :
 * updating form is reusable and contains only code related to the
   form action
 * link being in origin context, the developer knows where he is and
   where he wants to go
 * Menu oriented management offers a quick vision on how the screen will 
works

 * update-area seems to be a too technical name
 * we always have to manage area to update manually
 * too many areas to update become a headache and not only for the developer

We did not explain how we have done it, to try to focus the discussion
on the principles.

It would be a pleasure to have some criticism of this approach, and we
would try, in a second chapter to introduce other concepts that appeared
after the screens were made more dynamic and others to lowers the
identified cons.

Thanks,

The Néréide Team

[1] https://s.apache.org/rf94
[2] https://s.apache.org/g5zr
[3] https://s.apache.org/XpBO
[4] https://s.apache.org/YIL1
[5] https://s.apache.org/836D
[6] https://s.apache.org/DhyB
[7] https://s.apache.org/Lv9E
[8] https://s.apache.org/zKIo
[9] https://s.apache.org/D6jx