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
signature.asc
Description: PGP signature
