I'm in the process of developing a GUI extension to hide a schema field when the component loads. For now I am testing the feasibility in Firebug using the following code to get the actual field:

function getControlForFieldName(name){
    var fieldBuilder = $display.getView().properties.controls.fieldBuilder;
    var fieldsContainer = fieldBuilder.properties.input;
    var fieldsNode = fieldsContainer.getElement();
    var fieldContainer = $dom.getFirstElementChild(fieldsNode);
    while (fieldContainer) {
        var labelNode = $dom.getFirstElementChild(fieldContainer);
        var fieldNode = $dom.getNextElementSibling(labelNode);
        var control = fieldNode.control;
        if (control.getFieldName() == name) {
            return control;
        fieldContainer = $dom.getNextElementSibling(fieldContainer);

From here I am able to call it and I get the field successfully:

var fieldControl = getControlForFieldName('some_xml_field_name');   

I am now stuck trying to find a method that the fieldControl object can use to hide the field. I've tried fieldControl.disable() and fieldControl.dispose() with no luck. I also tried experimenting with the jQuery .hide() method but I can't seem to find a valid selector through this API.

I was thinking something along this form:


I think I'm close to solving the problem but I am missing one or two final pieces. Has anyone done this yet?

Also, in case anyone is wondering why I decided on the GUI ext. as opposed to a simpler method (such as instructions on the field description or educating users):

  1. I already have hundreds of components created using those schema fields and
  2. I'm migrating from 5.3 and this extension already exists - I need to continue supporting a similar functionality in 2011 SP1 - disabling the fields would work also.
  • 1
    That's definitely an interesting "legacy" support situation, thanks for the clear question and background addressing any "why would you..." type responses. :-) For a new implementation you'd probably consider adding any additional fields during publish (via the template package) or maybe even Application Data if these fields hold CMS-side type information not used on the delivery side. I'm curious--is the use case to always hide these fields? Does it depend on schema, user, etc? May 9, 2013 at 20:45
  • Hi Alvin, hopefully Haniel doesn't mind me answering this but thought it may be useful if the requirements were known. The functionality required was to hide/show certain fields when other fields had specific values. So if Field A had value "1", we'd show Field B and C. But if Field A was "2", we'd hide B and C and show D and E instead.
    – Alex Klock
    May 16, 2013 at 12:56

2 Answers 2


I seem to remember that old extension for some reason. ;)

You are pretty close... I rewrote some of the logic to the following:

var fieldBuilder = $display.getView().properties.controls.fieldBuilder;
    fieldsContainer = fieldBuilder.properties.input;
    fieldsNode = fieldsContainer.getElement();
    control = null;

$j(fieldsNode).children().each(function (index, elm) {
    var cntrl = $j('div.input', elm)[0].control;
    if (cntrl.getFieldName() === name) {
        control = cntrl;

return control;

Now once you have that control, you can just get the element from it and hide it like:


This works because the getElement() of the control will return the element matching div.input. We wrap the dom element into jquery, then call it's parent() method, which will return the entire div.field element that we can now hide.

Hope that helps!

  • Thanks Alex, works perfectly. Just one question, why did you change the original getControlForFieldName code to use jQuery to return the control? The original code works too. Is one more robust or efficient than the other? Just curious. May 10, 2013 at 14:53
  • It's just an alternate way since you are using jQuery already in your extension, if you didn't feel like crawling the dom manually. I haven't done my own performance tests yet to see if one would be faster than the other. The only thing I'd recommend from your script is to condense the var statements, and to use === vs == when checking for the name.
    – Alex Klock
    May 13, 2013 at 13:23

Out of interest, If you hide a schema field when the component loads, why would you have the schema field there in the first place? Would it be easier to simply not have the field in the schema?

I've used CSS to hide (not show the display) GUI elements in the past and it worked perfectly, i felt a bit more comfortable doing it this way in the event the CME View was doing additional processing on the item without my knowledge.


I've also written GUI extensions in the past that updated the properties of an interface element. To do so injected this code into my view when the view started:

$evt.addEventHandler($display, "start", onDisplayStarted);

function onDisplayStarted() {
        $("#elementId").disabled = true;

I suspect this might be the code you are looking for?

  • Yes, this is exactly what was I trying to do through CME view. The problem is that when I inspect the field elements, there's no unique id or class that I can use as my selector. Here's the actual html for one of the fields: <div class="field" style="display: block;"> <label title="Title (pr_title)"> <span class="asterisk">*</span> <a>Title: </a> </label> <div class="input"> <input class="text" type="text" value=""> </div> </div>. With regards to your first question, these fields were used in the past (but no longer) and I have many published pages with content from those old fields. May 9, 2013 at 20:24
  • To clarify my last comment: basically all the fields in the component appear to use the same <div class="field">...</div> wrapper. If I use $(".field") as my selector, than all the fields on the component will be hidden. I tried using the title attribute on the label $("label[title='Title (pr_title)']") just to see if I could hide this item but the html rendered by Tridion has line breaks in it and the selection fails. I've probably been looking at this for too long...but I'm sure there's got to be another way. May 9, 2013 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.