Table of Contents
Introduction¶
This guideline provides rules and recommendations on how to use the field
library and proxy fields in your business template. The field library is an
ERP5 form not accessible by the user. It is a container of proxy (template)
fields which can be used in other forms instead of recreating fields every time.
Make sure to distinguish between three levels of form fields:
- Core Template Form Fields
- Business Template Specific Form Fields
- Custom Form Fields
Why Field Library And Proxy Field?¶
Using proxy field is very useful for providing consistent UI and reducing code
duplications.
For UI¶
For example, comment field is one of the very common fields in whole ERP5 system
and it should be always the same size everywhere. Then we use proxy field, we can
define the height and width only once to the template field in the core field
library and the remaining is that all other comment fields just inherit the core
template field. This way, we can make consistent UI easily. If we did not use
proxy field, we had to set the same height and width for all comment fields one
by one, this is very hard to maintain.
About field library, this is a kind of buffer between the core field library in
erp5_core and the real fields to be displayed to users. We saw an example of
comment field above, it was a common field globally. But sometimes we want to
change an appearance of generic fields only in some business template. In such
case, we cannot change the core template fields, because they are used globally.
So we can change a field library of a target business template instead. Then we
can customize some fields only in a business template and this does not affect
UIs defined by other business templates.
For Code Reuse And Abstraction¶
Sometimes we can find similar patterns in ERP5. For example, when we use a
RelationStringField, we often name it like "my_source_title" by following our
naming convention. And from such names, we can find a pattern. The name suggests
this field uses source category and searches document by title. And we can make
a template field for RelationStringField and put a tales expression to parse
field id and find category name and index property. Once we have such a template
field which is an abstraction of a pattern we don't have to enter a category
name and an index property name each time when adding RelationStringField,
but just using a proxy field and inherit the template field is enough. We can
omit entering various parameters and it is also useful for maintenance, future
changes. Above is a very wide range example which can apply whole ERP5, but we
can find many other small patterns in a specific context managed by single business
template like Accounting, DMS. Therefore finding a pattern and making a template
field is very practical use case of proxy field and field library.
Define Once And Applying To Many¶
Sometimes we have to enter the same information in multiple places. For example,
a company has the same reference naming rule for Service and Product. In such case,
we have to apply the same input validation functionality to Product_view.my_reference
and Service_view.my_reference. Then we can say that both my_reference in Product_view
and Service_view are the same in reality. In such case, we should make a template field
in field library and reuse the field to inherit from proxy fields in both Product_view
nd Service_view. And in this way even if the input validation rule was changed, we
only have to update the template field and no need to touch proxy fields.
${predicate_view_as_book}