Manipulate DOM of app

Is it possible to alter the DOM of the an app after it's been rendered - in the case of our application we load a bunch of information and it would be nice to provide some simple show/hide detail toggles but I can't seem to find any methods that allow access to modify the DOM or even the app-specific DOM. What I'm looking to do is something like:

'click .detail': function(event) {

Any suggestions would be greatly appreciated.

Luke Bowerman, MerchantOS


  • 0

    I wanted to post the same question. In my case we want to make an app for conditional and cascading select lists. With the former widget structure we've done this, but with the new app structure I'm unsuccessful.

  • 0

    I realize my question is not the same, although the answer might be. I want to manipulate the DOM of the Zendesk interface (the ticket fields in this case). Not the DOM of the app itself. I hope anybody is able to give some insight on this.



  • 0

    Luke: yes, you can manipulate the DOM of your app. It requires only a small alteration to the code you provided:

    'click .detail': function(event) { event.preventDefault(); this.$('div.more').toggle(); }

  • 0

    Awesome! Thanks James.


  • 0

    Sebastian: what is it you'd like to do to the ticket fields? There's an API for showing, hiding, enabling, disabling, and setting their values.

  • 0

    James: showing/hiding is one, so that seems to be covered. Limiting the options in a select list (based on other values) is another, but I will experiment with that first. Didn't see that documentation when I first had a look at the new App structure (early July). I'm currently not assigned on a 'Zendesk project', so I will probably dig into this somewhere in October.

    Thanks for your answer.

  • 0


    I'm getting some weird behavior when I try to disable a custom field.  It appears that there are multiple versions of the element in the window DOM, and some of them get disabled.  Just not the one currently visible.  I am trying to prevent the field from being submitted with the page.

  • 0

    @Jeff: I'd like to understand your use case a little more. Let me walk you through a scenario:

    1. User u loads Ticket t
    2. t has custom_field_1234 set to "orange"
    3. Your app disables custom_field_1234
    4. u saves t
    5. Another user, v, opens t

    What would v see for that field? "orange"? Nothing? If Nothing, why doesn't your app set the value to null? Why do you feel that disabling the field should cause a ticket submission to change the value (from "orange" to Nothing)?

  • 0

    Perhaps I didn't express my problem clearly.  User v should see 'Orange'.

    In my case, I am using sending a request to the API to modify the custom field and add a comment to ticket t.  If the user simply left the page then, there would be no issue.  But if the user submits the page (with the old value for the custom field), the custom field is set back to its original value.

    I am also unable to update the field using this.ticket().ticketFields('custom_field_234234', "234").  I could use that to get around the fact that disable doesn't work.

  • 0

    @Jeff OK; let's solve the problem with this.ticket().ticketFields('custom_field_234234', "234") so you don't have to make a separate AJAX request to the API.

    What kind of field is custom_field_234234? If it's a tagger field, what is "234" in the call you're making? Is it the textual representation of the value, or the underlying value itself?

  • 0

    It's a decimal field.  I don't get an error, it just doesn't do anything.


    It would also be nice to have more accessibility to the DOM element.

  • 0

    @Jeff: We'll take a look at the field API to make sure it's working for all fields.

    What else would you like to change about the custom field element? Sebastian mentioned limiting the options of a dropdown, which is something we'll look into. Is there something else you would like to do?

  • 0

    I could see people being interested in implementing their own interface for a field.  I've had a thought about using a multi-line text field to store JSON or Markdown data and putting some kind of interface in front of it.  Of course, someone could implement the interface in the sidebar and just hide the element.  They would need to be able to execute some event before the ticket is submitted so that they could dumpt the changes back into the field.

    That kind of hook would be useful for me.

  • 0

    @Jeff: this.ticket().ticketFields('custom_field_234234', "234") is indeed the hook you're looking for. We'll investigate why it's not working for your app.

    I just realized that the correct method call is this.ticket().customField('custom_field_234234', "234") . Sorry for the confusion. Please let me know if that works for you. I'll ensure that the documentation uses the correct function name.

  • 0

    Thanks James.  That worked.

    Any thoughts on why this.ticketFields('custom_field_234234').disable() doesn't work?

  • 0

    The Data API doesn't say anything about this.ticketFields() , but the Interface API does. I'll make sure we clear up the confusion one way or the other. Thanks for finding this!

    I misread your question. We'll take a look at why this.ticketFields('custom_field_234234').disable() might not be working. It does work on other apps and on other accounts.

  • 0

    Is there a way to grab the value of the custom field specifically?  A normal jQuery method would be:

    $('.custom_field_234234 input').val(); but this does not work through the app interface.  

    this.ticketFields('custom_field_234234') returns an object. 

    How would i grab the value of those input fields?

  • 0

    @Benjamin: this.ticketFields is for interacting with the UI of the field. To interact with the ticket's data, you want this.ticket().customField() .

  • 0

    Thanks James!

    That was it.  On another note, the javascript parser built into the app creation is kind of limiting.  Basic functions like 'escape()' don't work with it. Also != does not work or == when comparing a string.  Just some thoughts :)


  • 0

    @Benjamin: Do you mean when uploading an app, the JSHint errors coming up? 

    It's basically making sure that you're using valid JavaScript and pointing out common gotchas. So there's likely something actually wrong with the way you're using something if it dings you for it.

    We'll post something up which will allow you to understand which JSHint options we're currently using (we're not actually that strict about it), but in the meantime you can use something like http://www.jshint.com/

  • 0

    While we're working on the full documentation that Jake described, I'll add a few guidelines here. escape is deprecated; you should use encodeURI for escaping whole URLs and encodeURIComponent for escaping path segments and URL parameter names and values. JSHint disallows == and != because they are too lax for most uses. We specifically do allow == null and != null for comparing with both null and undefined .

  • 0

    Jake and James,

    I did switch to encodeURIcomponent and that worked fine.  I was able to use == null which is why I was confused when == '' did not work.  I guess the most frustrating part is really the fact that in order to find out issues with the code, I had to save my work, compress the files and try to upload.  I suppose jshint.com might be a good place to test it out before uploading.

    Another issue was that it required a semicolon at the end of every line.  I know that it's good practice to use it and some languages require it, but I guess my bad habits with writing javascript were caught when the JSHint errors popped up with the numerous "missing ';'" errors ;)

    Thanks for replying and that makes perfect sense!  I do wish there was a little more documentation, but I was able to figure it out and get everything working.

  • 0

    Meant to say that the uploading a new .zip file for my app is really slow and seems to fail a good number of times which is why some of the simple mistakes take longer to fix.

  • 0

    @Benjamin: We hear ya - We'll be working on way to enable easier app development in the future, but for now I'm afraid the .zip-hurdle is gonna stick around for awhile. 

Post is closed for comments.