All work

Select view

Select search mode

 

AbstractClassPackage must support activated_classcollections

Fixed

Description

I think we have a big missconception. We use the AbstractClassPackage as a "dropin replacement" for the to replace the AbstractClassCollection. This is actually NOT working as intended because if you have added a classCollection name to your XWikiPreferences field activated_classcollections then this ensured that the class of your selected extension are getting generated. YET if the developement of your extension is changing to use the new AbstractClassPackage the classes won't be generated and updated anymore.

We need to get back and check for all replacments of usages of the AbstractClassCollections with the AbstractClassPackage and need to write for each replacement a Migration checking on the XWikiPreferences and converting the activated_classcollections field to the new celements.classdefinition.active

Details

Priority

Assignee

Reporter

Components

Story Points

Time tracking

1h logged

Sprint

Fix versions

Clockify

Created 8 July 2017 at 16:45
Updated 28 July 2017 at 13:25
Resolved 28 July 2017 at 13:25

Activity

Fabian Pichler 
18 July 2017 at 19:47
(edited)

thumbs up approved.

I have seen, that you fixed PageTypeClassPackage in the same PR.
Yet, please add issues to the projects needing a fix for the other packages to change them as soon as the new celements-core is released and adopted.

Marc Sladek 
17 July 2017 at 09:34

I like the suggested improvements thumbs up see PR

Fabian Pichler 
16 July 2017 at 13:43

thumbs up I would prefer to distinguish between Packages needing a legacy fallback and new Packages never been available as ClassCollection. This could be achieved by providing two different abstract classes: AbstractClassPackage and AbstractLegacyClassPackage only the second implements isActivated with a fallback lookup and logs a warning that the fallback was needed and might be removed in future versions.

wdyt?

Marc Sladek 
10 July 2017 at 15:22

Marc Sladek 
10 July 2017 at 12:41
(edited)

Yes, I see the problem. Another idea: why not add a legacy fallback to ClassPackage.isActivated() which, if the default implementation would return false, checks e.g.:

@Override public boolean isActivated() { [...] if (!activated && getLegacyName().isPresent()) { String preferences = "," + context.getXWikiContext().getWiki().getXWikiPreference( "activated_classcollections", context.getXWikiContext()) + ","; activated = preferences.contains("," + getLegacyName().get() + ","); } return activated; } protected Optional<String> getLegacyName() { return Optional.absent(); }

The legacy config name can be overwritten in the affected ClassPackages