Trouble when multiple widget have the same name

[sghpjuikit]

Infinite recompilation cycle. Can happen when user clones a widget to use it as a starting point.

[sghpjuikit]

This issue relates to the fact that component id and component ui name are misused (with name sometimes playing the role of the id). This is because exported components do not really have a concept of id at this point.

Another issue is the fact that widget type id is the same as the directory of the widget. This is convenient as it guarantees uniqueness of the id, but not of the name, which when used as id (see above) causes an issue.

I have renamed the relevant methods to better disambiguate the id and name, but more work needs to be done to avoid the issue.

[sghpjuikit]

Also causes widgets opened through templates to not show gui compilation progress

[sghpjuikit]

Infinite recompilation cycle fixed in a2e1d87f by asserting compilation result (class name and package name must match widget directory name).

The problem with ids has been improved in e9d79001: Widget.name is no longer used for identifying purposes, instead Widget.factoryId has been introduced.

I'm still planning to turn factoryId into UUID, rather than text containing the widget directory name, to prevent collisions, but at this point I can finally sleep at peace.

[sghpjuikit]

I fixed related issue: unrecognized widgets created using extension WidgetFactory.orNone() did not reload after recompilation nor show recompilation.

The former was caused by using name instead of factoryId (see above), while the latter stemmed from the issue of recompilation identity - during recompilation time, factory may not exist (only factoryId) and thus it could not match any recompilation entry. Recompilation entry identity was changed to widget location. This ties nicely into WidgetFactory.identityId, which is tied to Widget.controller class name, which must conform to name of this location.

This completes the identity issues. to reiterate the various identities involved:

• widget name - defaults to widget factory's name, but can be overriden by user
• widget id - unique per widget instance id
• widget factoryId - widget factory id
• widget controller class name - derived from widget location
• widget factory name
• widget factory location - location of the widget
• widget factory id - unique per widget type id, derived from widget controller class name
• widget factory recompilation id - same as widget factory location
• widgetMonitor name - unique, same as widget factory.id
• widgetMonitor widgetDir - widget location, unique id

There are also widget factory implementations returning concrete widgets, 'empty' and 'load fail' factory as well as component factories that can load entire layouts - these do not have a location and id. So this was difficult to get right.

There are still minor improvements to be made, most important of which is the lack of empty content for components, in the same vein as for widgets, to allow to wait and reload when the component becomes available to the application.