We have moved to GitHub Issues
Created by Andy Butland 21 May 2016, 21:08:56 Updated by Lars-Erik Aabech 13 Jun 2018, 13:25:45Tags: PR
I saw a tweet suggesting this and also thought would be a good idea - to support a scenario where you've created a document type but then realise that part of it would be better as a composition. A bit like an extract class refactoring.
So when editing a content type - if it's saved and not already used in a composition itself - you could select a set of properties that a defined on the type (and not already inherited), provide a name and create a composition type. The selected properties and associated tabs would be moved or copied as needed to the composition type and a relation set up between it and the content type being edited.
Having been taking a look at implementing this so creating this issue for the tracker.
@abutland This is a game changer! So happy you've done this.
Quick question, will this support extracting identically named properties from two different doctypes?
i.e. Previous developer instead of using compositions has duplicated properties amongst different doctypes.
Hmm - not tried that and it's beyond what I've looked at so far. As it stands it the process moves the field to the new composite type, which is empty of course as it's created new, but if allowed to pick an existing could then have a clashing alias with the one already there.
Will have a think but it sounds quite a bit more complex to actually combine the property types or merge with existing ones - could be they have the same alias but different data types (so aren't identical), and if content associated of course that would need to be moved. What I've done so far is actually quite simple content wise - as it's just the property type moving to a new content type, the content just keeps the same association and doesn't need to be touched.
I've made some further additions to the PR to support extracting a composition into an existing type. It is a bit more complex but should be more useful, supporting things like the scenario James notes above.
@abutland Excellent! :)
BEWARE - need to check how this is working. Need to ensure that it is deployable which is not obvious since Deploy deploys a state, and moving property data around might mean losing some values. This should probably be deployed as an "operation" to be performed on target environment. Just make sure NOT to create something that is NOT deployable.
This looks like a great idea! I came across it when looking for something similar. I was looking for a way to extract properties from a doctype and move them to a composition but at the same time move all data already stored on those properties. Looks like this is on hold until v8?
@ProNotion Last I heard it's on hold because Deploy(/Cloud).
Type: Feature (request)
Backwards Compatible: True
Fix Submitted: Pull request
Due in version: 8.0.0