The purpose of this document is to define how to configure the BT5 to order to automatically handle skin folder ordering in the skin selections. This will help no to manually edit this order after
an installation/update.
Table of Contents
Current status¶
Here is the description of the current functionalities (2009/08/25).
Configuration¶
It is possible to set 2 priorities on the skin folders:
- business_template_registered_skin_selections, which allow to set only the skin folder only in a defined skin selection (skin folder without this property are put in all skin selections)
- business_template_skin_layer_priority, which is use to sort the skin folder in the skin selection
Those priorities are exported with the skin folder by the 'template_skin_id_list' properties of the BT5.
The BT5 are responsible to modify the skin selection order after an (un)installation.
Troubleshooting¶
- it is not possible to automatically sort the skin folder order without installing/updating a BT5
- it is not possible to add an existing skin folder to a new skin selection
- it is not possible to remove a skin selection
- hardcoding skin folder priority increase maintenance difficulty, as it does not provide explicit relation between relation between skin folder
Proposed solution¶
Here are the possible configuration to allow a clean automatic ordering management.
Skin Tool should be able to reorder automatically¶
The automatic reordering functionality will be moved from BT5 to Skin Tool.
By adding a new tab on Skin Tool, it will allow for Manager to test its configuration, without having to reinstall/update a BT5.
This should also automatically remove unused skin selection (ie, if a skin selection is not explicitly define on a skin folder or if it is not the default skin selection).
Comment by yo: I object to adding a new tab. It is better to replace the properties tab. You can just add a new button (e.g. Refresh Skin Selections). Also, it would be nicer if the action only
proposes new data without saving it automatically, so that Manager can stop updating it.
Comment by jps: consider moving skin tool to subclass of ERP5's BaseTool, like julien did for TypesTool. Anyway, this will happen sooner or later.
Add a relative order property on the skin folders¶
This new property will explicitly define than an skin A should have an higher priority than skin B.
Example: on A, business_template_skin_layer_precede: B
This should handle REGEXP (example: erp5_.*).
In case of circular dependency, an error should be raised. The manager have to manually fix it before calling the automatic sort.
business_template_skin_layer_precede has an higher operation priority compared to business_template_skin_layer_priority.
Comment by yo: I like the idea, but I don't like the name. Please follow the ERP5 convention. precede is a verb, so it should be a part of a property name.
Comment by jps: One more thing. It would be helpful if we can have a tab to set the expressions to all skin folders on a single screen.
Example:
- A define: business_template_skin_layer_priority = 200
- B define: business_template_skin_layer_precede = A
- business_template_skin_layer_priority = 0
- The final order should be:
- B,A even if A has an higher priority
Explicitly export skin folder properties in the BT5¶
BT5 should not implicitly export business_template_registered_skin_selections, business_template_skin_layer_priority and business_template_skin_layer_precede anymore.
Instead, those definition should be explicitely defined by 3 new BT5 properties.
This is the main feature which will allow to have a correct order after an installation.
Example: in the erp5_mobile BT5, it will be possible to add the skin folder erp5_xhtml_style to the Skin Selection Mobile, even if erp5_xhtml_style is installed by another BT5.
Define a convention for business_template_skin_layer_priority¶
Priorities should go from 0 to 100.
Business Templates in /public/erp5/trunk/bt5/ should have low priority numbers (0 to 50) if needed.
Customer business templates should go from 51 to 90.
The highest priorities (91 to 100) should be reserved for developers. Ex: 100 for custom.
FAQ¶
Is the compatibility kept?¶
Yes. The only requirement is to update all BT5 to explicitly define the skin folder properties.
Conclusion (JPS)¶
All objects handled in bt5 will sooner or later become ERP5 documents which are going to implement part or all of ERP5Type.Base APIs. This is happening already for portal types. Therefore, rather than
patching of extending CMF classes, which anyway will be dropped, it is a good time to move to ERP5ish documents. Therefore, please do the following so that we do not have to reimplement in 1 or
2 months:
1- Create a new SkinTool subclass of BaseTool (as Julien how to do in a way which is transparent and compatible)
2- Use ERP5Type.Folder (or a subclass) for all skins folders. Compatibility can be handled the same way.
3- Use existing ERP5 properties to implement your ideas. In your case, if seems that predecessor_text or successor_text are the appropriate properties to represent the constraints between skins.
int_index seems to be good to represent priorities. Do not hesitate to drop some of the properties (making sure though in compatibility code that we do not lose information)
FYI, this idea was implemented for portal types, which is tremendously more complex, in less than 2 weeks. So, this should be fast.
Related Articles¶