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 | |
   | |-| |
   | || |
   | | | |
   | |  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




signature.asc
Description: PGP signature

Re: [DISCUSSION] Make Back-Office screens dynamic

[Gil Portenseigne]

Hello James,

Thanks for the reference we will look into that.

Regards,

On Fri, Jan 10, 2020 at 03:50:23PM -, James Yong wrote:
> Hi Gil,
> 
> I wonder if this library helps for a start:
> https://github.com/joshualjohnson/jquery.x
> 
> Regards,
> James
> 


signature.asc
Description: PGP signature

Re: [DISCUSSION] Make Back-Office screens dynamic

[James Yong]

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-target="PartyRolesCustom">
> 
> 
> 
> 
> 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"/>
> 
>  from-field="customerParty.partyId"/>
> 
> 
> 
> And the form :
> 
> 
>
>...
> 
> 
> With this logic you can define a new usage of createPartyRole
> without redefining a form just :
> 
> 
>  from-field="partyRelationship.partyIdTo"/>
> 
>  from-field="partyRelationship.partyIdTo"/>
>  value="IRL_LIKE"/>
> 
> 
> 
> 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: OFBiz features/functions overview in the wild

[Michael Brohl]

This is the english version: https://www.capterra.com/p/164046/Apache-OFBiz/

There are similar websites providing such informations with very 
different quality. In a few occasions where I tried to get the data 
updated/corrected I learned that I would have to pay for it. Seems most 
of them are targeted to commercial software vendors.


It would be interesting how it works on this website. If there isn't 
anyone working on this I'll see if our team can clarify with the website 
owner.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 09.01.20 um 10:45 schrieb Pierre Smits:

Hi Jacques,

There are (as far as I can tell) 3 possibilities where this is coming from:

1. It is automagically scraped from our official documentation (by
crawling through our pages on the site and wiki) and collated
2. it is taken from what is in the definition on
https://projects.apache.org
3. it is a manual action to provide that information (when this Dutch
site is different from others)

Regarding aspects 1 and 2 the solution would be to insert the applicable
and appropriate keywords in our artefacts, so that they get reflected in
such sites.

Digging a little into the website I found that it is US based and
affiliated with Gartner.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Thu, Jan 9, 2020 at 10:31 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Pierre,

Right, how can we fix that though?

Jacques

Le 09/01/2020 à 10:01, Pierre Smits a écrit :

Hi all,

Recently I came across this Dutch website (
https://www.capterra.nl/software/164046/apache-ofbiz)  that states
functions about our product. I don’t know where this originated but I
presume somewhere data is is pulled/scraped from our official elements.

The most important thing I want to bring to the attention of this

community

is that under the functions section (I am confident you can find similar
sites in your country/language that shows the same) it does NOT highlight
key features/functions like purchasing, order management, planning,

project

and time management. This should be corrected asap.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve , committer






smime.p7s
Description: S/MIME Cryptographic Signature