Forums/Community/Zendesk Apps

Manipulate DOM of app

Luke Bowerman
posted this on July 30, 2012 22:11

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) {
  event.preventDefault();
  jQuery('div.more').toggle();
}

Any suggestions would be greatly appreciated.

Luke Bowerman, MerchantOS

 

Comments

User photo
Sebastiaan Wijchers
mediacompetence

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.

July 31, 2012 00:11
User photo
Sebastiaan Wijchers
mediacompetence

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.

Cheers,

Sebastiaan

August 02, 2012 01:51
User photo
James Rosen
Zendesk

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();
}
August 07, 2012 17:42
User photo
Luke Bowerman

Awesome! Thanks James.

luke

August 08, 2012 09:32
User photo
James Rosen
Zendesk

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.

August 15, 2012 11:22
User photo
Sebastiaan Wijchers
mediacompetence

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.

August 16, 2012 00:41
User photo
Jeff Mace
continuent

James,

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.

August 17, 2012 13:41
User photo
James Rosen
Zendesk

@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)?

August 17, 2012 14:25
User photo
Jeff Mace
continuent

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.

August 17, 2012 14:35
User photo
James Rosen
Zendesk

@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?

August 17, 2012 15:13
User photo
Jeff Mace
continuent

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.

August 17, 2012 16:47
User photo
James Rosen
Zendesk

@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?

August 17, 2012 16:50
User photo
Jeff Mace
continuent

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.

August 17, 2012 17:10
User photo
James Rosen
Zendesk

@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.

August 17, 2012 17:13
User photo
Jeff Mace
continuent

Thanks James.  That worked.

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

August 22, 2012 07:47
User photo
James Rosen
Zendesk

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.

August 22, 2012 08:50
User photo
Benjamin Rojas

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?

August 30, 2012 15:08
User photo
James Rosen
Zendesk

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

August 30, 2012 15:50
User photo
Benjamin Rojas

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 :)

-Benjamin

August 31, 2012 12:49
User photo
Jake Holman
Product Manager

@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/

August 31, 2012 12:53
User photo
James Rosen
Zendesk

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.

August 31, 2012 12:58
User photo
Benjamin Rojas

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.

August 31, 2012 13:14
User photo
Benjamin Rojas

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.

August 31, 2012 13:15
User photo
Jake Holman
Product Manager

@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. 

August 31, 2012 13:16
Topic is closed for comments