Easily Move a Type to Another Theme

Comments

11 comments

  • Avatar
    Kevin Bedward

    I have noted your request - thanks Peter

    0
    Comment actions Permalink
  • Avatar
    Giles Middleton

    I'm guessing you mean magically move a type and all instances of that type from one theme to another, by just using Manage Themes and not the Explorer bar?

    Which removes the pain of having to create matching fields, and attempting to map differences?

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    Yes, that is correct.

    Except, I think it should not be necessary to invoke magic; types should just have a simple reference to a theme, making it simple to move a type to another theme. After a type has been moved to another theme, the "Manage Repository" dialog is closed, and the explorer is refreshed, the elements of the moved type will naturally be shown under the new theme.

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    The problem here is that you may have an existing complex hierarchy of elements.

    E.g Type A and Type B in your theme and you have:

    A1 child B1 child A2.

    How do I then move Type B to a new theme?

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    Types just have a reference the theme they belong to. Moving a type to another theme, is done by changing the type's reference to the other theme.

    Nothing else, incl. elements, relationships, and fields, does not have any concept about themes, so nothing else have to change.

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    But that would mean that any type from any theme could be a child of any other type from any other theme?

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    Ahh, now I get it. I had not thought about that scenario.

    I think the assumption should still be that all element types used in the same hierarchy, must belong to the same theme. Then you may have to move multiple types at the same time.

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    Hmm... on the other hand, I could image useful scenarios where a theme contains generic types that should be used as child elements in multiple other themes.

    0
    Comment actions Permalink
  • Avatar
    Kevin Fairs

    Peter, Hi

    We discussed this in the roadmap team today, and rated it as something we would like to iterate a bit more.

    We perceived that the challenge you were having was moving instances of types between themes, and that moving types might have been a solution. We also noted Giles comments about trickies in the story as raised, and postured that an alternative approach might be to raise a subtly different story enabling the duplication of types between themes.

    This could give a multi-stage process to migrate content, giving the user the time and space to properly consider the movement of elements across the theme boundary. (particularly important in hierarchically arranged themes).

    1. Duplicate type

    2. Move instances as required. Assuming themes have the same relationships (including both source and target), then no data should be dropped here.

    3. Remove original type

    How does that feel / do you think it might fit the need?

     

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    It feel like there I need to take a backup first, try the move, then verify that it was successful, i.e. check that no data was lost. In order words, it feels like things can still go wrong. The assumption you write in step 2, I think should be a step on its own.

    What about a wizard with these steps:

    1. User select theme, then types within this theme to be moved
    2. Wizard check if there are other element types in the element hierarchy that will prevent the selected type from being moved
    3. User select theme where the types should be moved to
    4. Wizard duplicates the selected types, modifies relationships, moves the elements, deletes the old types

    This way the wizard helps with the difficult parts and verify the right prerequisites so no data is lost.

    1
    Comment actions Permalink
  • Avatar
    Karl Hertz

    I realise I am a bit late to the party here, but I want to support this from our perspective. This is something we have done a couple of times and it is a real pain. What we would like to be able to do (using the "wizard approach" - so some magic involved after all) is:

    Select the element types we want to move. We envision three possible cases

    1. Hiearchies are "simple" (i.e. all elements of the type are only in hierarchies which only contain this type of element)

    2. Hierarchies are "complicated" (i.e. all elements of the type are only in hierarchies with parents which are strictly of the same type or are top nodes)

    3. Hierarchies are "muddled" (i.e. elements are distributed throughout its "main theme" without any ordering

    The "simple" approach is fairly straight forward in that what needs to update is where the theme is "placed" and then to move all the instances of that theme to it's new main theme. Relationships to/from the theme and all instances should be retained.

    The "complicated" and "muddled" approach is a bit more, well, complicated. Here, we would like to be given the option of moving the themes and all themes which are affected to its new main theme. We realise this could be quite a bit more complex. The criteria for when something can not be moved in this fashion is if the affected themes have parents in themes which would not move (e.g. you get a set of boxes you have to "tick" to be able to do the move).

    Other than this, we like Peter's "wizard" idea. We would like to add that queries and matrices would potentially be affected, so those would have to be taken into account as well...

    0
    Comment actions Permalink

Please sign in to leave a comment.