Multiple embedded schema types in embedded schema field

Question

Is it possible within Tridion 2013 SP1 to have an embedded schema field that allows more than one type of embedded schema. I was wondering if anyone has tried this using a complex schema or knows of any other ways this could be achieved. I would like to achieve the following:

Schema A (Embedded Schema)   
Schema B (Embedded Schema)
Main Schema (Component Schema)
     - >Field A (title)
     - >Field B (Embedded Schema Field Allowed Schema's (Schema A, Schema B))

I know I could achieve something like this with a component link field but that isn't very elegant in terms of a content editor. Any help or advice would be much appreciated on either achieving this, complex schema's or examples of something else that may work. Even if the advice is to tell me this is not possible.

Many thanks

Edited

Thanks for your responses guys. I thought this was the case but thought I'd ask. The reason, as Rob has mentioned, was for user experience. I figured I would either have to go down a GUI extension or component links route but good to hear it from other people before I decide on an approach.

Thanks

Answer 1

Not as far as I know but I guess one approach would be to add all the fields to a single embedded schema and then instruct users to use the correct fields based on the type - the type being determined by a drop down field.

You could take it one step further with a GUI extension to hide the fields based on a naming convention e.g. if the value of the first field was "event" only show fields which are prefixed with event_ or something.

However, I'd recommend Component Links unless your real value is the improved user experience of not having to create lots of components to create one thing on the page (which is what I'm guessing you're going for).

You could even write a GUI extension that created Components in the background and bought the fields from the selected schema into the same window but there would be lots of things to think about and it would probably fairly involved to write.

Answer 2

As far as I know, there is no provision to allow more than one schema type on Embedded Schema Field.

But I think you can try this by modifying the source of the schema (I haven't tried this option yet).

By the way, it's not a good approach.

From my experience, I would suggest to have Component Link field which allows more than one schema type.

Advantage is, you can reuse the content and translation will be limited (Hence, Less cost is involved). If you opt with Embedded schema, you need to send same content for translation couple of times and which costs high.

Answer 3

Show / hide logic in Tridion Schemas?

A text fields that uses a Category (with nested Keywords presented with the Tree option) is probably the closest thing we have in Tridion that presents additional options after a user selects an initial option. But this only works for selections.

Separate Schemas Rather than Component Links

For two Schemas with different fields, but a common Title or Heading, I'd recommend separate Schemas rather than a GUI extension or Component links as seen below:

Main Schema A (Component Schema)
     - >Field A (title)
     - >Field B (Embedded Schema A)

Main Schema B (Component Schema)
     - >Field A (title)
     - >Field B (Embedded Schema B)

If the title, A, or B were usable or presentable on their own I might suggest three Schemas, especially if using Experience Manager, SDL Mobile, and/or SmartTarget.

I point out when near duplicate schemas make sense in this post.

Advantages of separate Schemas (not Component links) include permissions control and the ability to set a default set of fields (linked Schema as a default) for a given folder. Having them separate also simplifies template development and dynamic functionality (query by Schema rather than if/else logic in templates).

Recommendations if you separate Schemas:

• If they're related, use a naming convention that places the two Schema next to each other in the drop-down list (e.g. Article Press Release and Article Blog)
• Optionally use the same field names, to simplify template development
• However, use specific field descriptions (see tips in this post)

Extension Recommendation

If you do Component links, be sure to restrict the options to only the right Schema.

For a GUI extension or automation with the Event System, I'd look at the entire editorial process, including Experience Manager (XPM). For a given task in terms of creation, updates, and re-use (read that as a variation on CRUD), I'd look to optimize the most tedious parts for editors.

For example, even with a Component that had all the fields, if using XPM Page Types or Content Types, creation is optimized since editors don't need to fill out all the fields. However, edits and re-use might be harder because you have more fields in fewer Schemas.