I'm gathering requirements for "Custom Content Editor Screens" and am familiar with at least two ways to extend component form fields.

  1. Custom URLs. To extend the component view we can use Custom URLs along with /WebUI/Core/Controls/Popup/PopupInit.js in the pop-up to get and set fields into the component.

  2. Field Builder. There are a few examples on the field builder directly in the component view :

Using either of the above approaches, authors would set a value in a pop-up, then a save or update button would update the value into a component field. I see how this would also work for "non-standard" SDL Tridion field controls such as a slider (e.g. jQuery UI example slider).

But do we have an (ideally supported) approach on how to add/change CME field controls in the component form view (inline), without needing a pop-up?

Update: Examples

  • Instead of just a number box, display the box and a "slider" next to it inline. Author drags the slider and the number box updates in real-time.
  • Show an image cropping or X/Y selection interface within the form view. Author clicks in a box and fields for X and Y get updated.
  • Display nested keywords as multiple drop-downs ("a dynamic selection" of sorts)
  • What exactly do you mean with "an approach on how to add/change field controls in the component form view, without a pop-up", do you mean something like, somebody typing a value in the field (that is supported already ;o)? Or are you thinking along the lines of setting the field value by means of a button, that would essentially be the same approach as using the popup, but then skipping directly towards passing the value back. – Bart Koopman Sep 9 '13 at 8:20
  • Good question, I wasn't that clear. I'm thinking the field types and how they're saved would be the same (text, number, etc), but we'd include updated/new controls inline, within the component form view. – Alvin Reyes Sep 9 '13 at 16:51

I'm not really sure I fully understand your question but here goes:

When you add new inline controls, they will be linked to a Schema field somehow, so in the place of an existing field which you are then hiding I guess. So that new control, should hold a value somehow, and when that is set, it should send that value back to the original field (the hidden one) the same way a popup would do that.

Mind you, I would always recommend against hiding the original fields in the standard tabs as it can bring confusion. But lets say you have a number field in your Schema and want a slider to set it. You can use the described popup approach, or just place the slider below the number field, and still allow the customer to set the number field by hand. Or optionally, disable the number field, but still show it so it is clear where that value of the slider ends up.

  • +1 and accepted. I completely agree with not hiding or changing the original fields. I'd want to let "power users" to use keep using the component form in the typical ways. I can run with this next I find an available technical resource in about 2 weeks. ;-) – Alvin Reyes Sep 12 '13 at 3:33
  • I guess I was wondering how to do "Field Behavior Injection" before it was a thing, though I couldn't ask clearly. – Alvin Reyes Sep 1 '14 at 11:38

Your Answer

