This article aims to suggest some best practices related to the registration of items in the Promob Catalog. These suggestions take into consideration certain established system behaviors. Given the impossibility of predicting or blocking all possible registration alternatives, we understand that best practices are more effective in specific situations. These are not rules, but rather suggestions based on identified cases, from which recommendations can be made to prevent some undesirable behaviors.
If you have any doubts or encounter any behavior related to these best practices, we suggest opening a support request.
General Changes in Item Registration
General Registration of New Items
Copying Items from Other Libraries
Items with Permission to be Disassociated
Maintenance in !find or CHECKED Type Assemblers
Events with Action - Reprocess Aggregates and Siblings
General Changes in Item Registration
SITUATION: After modifying existing items in the library, inconsistencies or undesired situations may occur when opening an old project containing that item.
RECOMMENDATION: Before releasing the change to all users, we recommend a partial release (only for a specific serial number), and in this Promob, open an old project and perform basic tests related to what was changed (Models, Aggregates, Sizing, Budgets, etc.).
General Registration of New Items
SITUATION: After registering a new item and publishing the library to Promob Studio/Start, inconsistencies or undesired situations may occur.
RECOMMENDATION: Before releasing the media with new items to all users, we recommend a partial release (only for a specific serial number), and in this Promob, create and save a new project, reopen it in the same Promob, and perform basic tests related to the new item (Models, Aggregates, Sizing, Budgets, etc.).
Replacement of Aggregates
SITUATION: In the registration of Aggregates for a module, there are fields for Module/Group ID and Aggregate ID (each with its purpose), but where it is possible to replace the information entered there.
RECOMMENDATION: Whenever it is necessary to change a Module/Group ID of an Aggregate in the module, instead of directly changing the information in the existing Aggregate, which has a unique Aggregate ID, it is recommended to make a copy or create a New Aggregate to then enter the desired new Module/Group ID in it. This way, the previous registration remains in the format it was until then, avoiding undesirable situations in old projects that already contain that inserted item.
System Performance
SITUATION: Some registration actions may require longer system processing times. Among these registration actions, we highlight:
- Excessive use of Events;
- Excessive use of test-based Conditions, such as !find or CHECKED;
- Use of Drawings with excessive details.
RECOMMENDATION: If you notice any slowness related to specific items in the library, we recommend conducting comparative tests with similar items that do not exhibit slowness, evaluating the need for that registration format and possible alternatives.
Creation of New Attributes
SITUATION: Immediately after creating a new Attribute in the System Menu - Registration - System - Attributes, crashes or inconsistencies occur, even if the new Attribute is not being used in item registration.
RECOMMENDATION: After creating a new Attribute in the System, we recommend that the library be reindexed right after Menu - Registration - Reindex - Biblioteca, and then close and reopen Promob Catalog.
Copying Items from Other Libraries
SITUATION: After copying files between one library and another (whether within Promob Catalog or by directly copying folders/files through Windows directories), information is lost or inconsistencies are generated in the system.
RECOMMENDATION: We do not recommend copying any information between two libraries, not even using the Copy and Paste tools available in Promob Catalog, except in specific cases indicated by Promob's technical departments.
Items with Permission to be Disassociated
SITUATION: Depending on the registration format, there are Aggregate items that can be disassociated from the module to which they were linked. In this process, the disassociated item may exhibit undesirable behaviors (lack of information, incorrect resizing, inconsistencies, etc.).
RECOMMENDATION: For items that can be disassociated, avoid registering actions based on information retrieved from the parent item. And when it's necessary to retrieve information from the parent, block the disassociation action.
Use of @ Symbol
SITUATION: After registering a formula, the system doesn't return the expected value.
RECOMMENDATION: If the system doesn't return the expected value, it's recommended to use the assembler @(FORMULA), as in some cases, the presence of @ reinforces processing, thus providing the expected result.
Maintenance in !find or CHECKED Type Assemblers
SITUATION: !find and CHECKED type assemblers work by checking aggregates, retrieved from the IDs of items specified in the assembler itself.
RECOMMENDATION: When using these types of assemblers and needing to perform maintenance on related item registrations, carefully observe the IDs used in the assemblers before making any changes.
Events with Action - Reprocess Aggregates and Siblings
SITUATION: Upon reopening a project, changes in finishes, item dimensions, or module aggregates are noticed.
RECOMMENDATION: Check for the presence of Events with actions to Reprocess Aggregates and Siblings, as these Events can affect various levels of registration. Therefore, it's recommended that this specific Event and action be applied at the lowest level of registration (child items).