fieldenms
Entity: suport for glyphs
Description
Every entity has a key and many have descriptions. Either key or both are used for representing entity instances textually (e.g., in logs) and graphically in UI. There are situations where a graphical representation of entity instances could be benefit from rendering glyphs (little icons) that could provide some additional cue about the nature of entities. Glyphs do not need to be unique for each entity instance. Instead, the could be categorising, assisting with "grouping" entities visually in some natural for that entity and domain way.
For example, in the asset management domain, where we mostly work, work orders (WO) have natural categorisation by their types (e.g., preventive maintenance, breakdown, recall). Each WO type could have its glyph, uniquely representing each type. And work orders could be rendered in the autocompleter and EGI with a glyph that corresponds to their WO types.
At the same time, following this example, rendering WO types during autocompletion an in EGI, would use glyphs associated directly with their instances.
Hopefully, the above elicits the idea well enough. Let's now consider modelling and implementation aspects of this proposal.
Glyphs should represent a finite set of standard and application specific icons, which can be referred to by their iconset name and icon name, such as icons:opacity. Persistent entity EntityGlyph (or EntityIcon, whichever name is considered more natural) should be introduced at the platform level. It should have a composite key, consisting of property name: String with values such as "icons:opacity" and colour: Colour (| could be used as a key separator). Such key should allow entry of glyphs with the same icon, but different colours. Property desc should not be required, but could be used for listing alternative glyph names for ease of search. Property colour: Colour should be taken into account when rendering glyphs. Every supported icon should be pre-populated into the target database.
It should also be possible to add new glyphs over time at an application level, so a corresponding centre and master could be useful. But this should really be an application concern.
Domain entities that have a property of type EntityGlyph should be rendered by the autocompleter (autocompletion list only) and EGI (inclusive of this). It is easy to envisage cases where glyphs should not be rendered even though they are present. It is proposed not to render glyphs by default. Instead respective Entity Centre and Entity Master DSLs need to be enhanced to support a way for specifying what property should be used for rendering. If such property is specified then glyph rendering should occur. The implementation should validate that a specified property is of type EntityGlyph. A fetch model for autocompleters, used in selection criteria panel and Entity Master, as well as for an Entity Centre result set, should be adjusted automatically to take into account properties for glyphs.
Glyphs should be rendered to the left of a key value.
The above example describes 2 situations -- a glyph rendering for WOs by associations with their types, and a direct glyph rendering for WO types. From the modelling perspective, only WorkOrderType would need to have property glyph: EntityGlyph. If WOs where to be rendered with a glyph representing a corresponding WO type, Entity Centres and Masters would need to specify a dot-notated property path such as workOrder.woType.glyph or woType.glyph (for WO itself) -- the path should always be context dependent. So for values of type WorkOrderType itself, it would be just glyph.
Special considerations for rendering of EntityGlyph
As any entity, instance of EntityGlyph would be autocompletable, and it would be required to render autocompleted values with glyphs. However, because entity EntityGlyph does not have a property of type EntityGlyph, which could be handled as per discussion above, instance of this entities should have special consideration at the autocompleter level to always render then with a corresponding glyph and colour, defined in their property glyph and colour respectively.
There is no need for any special consideration of EntityGlyph in EGI due to support for rendering customisation.
Expected outcome
Enriched rendering capabilities for entities.
