Forums

edit() Method of BlockController - Help

Permalink
The documentation says with regard to the edit() method of a block controller...

"This function is automatically run when the block is edited."

That's a bit vague and unclear. Does that means it runs before the block's edit dialog appears?

> That makes it useful when paired with $controller->set()
> or $controller->addHeaderItem()."

So I created a method called "edit" in my controller and am trying to add a header item, but the item doesn't appear when the block is in edit mode. I'm confused. Can anyone clarify what this function is supposed to do and how to use it?

Thanks much,

-Steve
Shotster
 
andrew replied on at Permalink Reply
andrew
save() is run when the block is submitted/saved through the API, and edit() is run when the edit interface is displayed.

As of 5.4, $this->addHeaderItem() should work within the edit() method, but it's a little dicey, because it has to be loaded through AJAX. This should work with HTML and JS, though.
Shotster replied on at Permalink Reply
Shotster
Thanks for the quick reply, Andrew.

> As of 5.4, $this->addHeaderItem() should work within the edit() method

I'm running 5.4.0.5, and my JS does not appear in the doc head.

> but it's a little dicey, because it has to be loaded through AJAX.

I'm not sure how to read that. Does it mean that it's not guaranteed to work? I can tell the method is running, because when I echo a string, it appears in the edit dialog. However, the reference to my JS file does not appear in the doc head.

> This should work with HTML and JS, though.

It's not clear to me what you mean by that.


Sorry, but I'm still confused. Should I just not rely on this method to load doc head items or what?

-Steve
andrew replied on at Permalink Reply
andrew
It sounded like CSS and/or JS wasn't loading through edit() addHeaderItem(), and I just meant to say that that might because a browser wasn't happy loading it through AJAX, and that if that were the case, we should have a bug on it. But since it sounds like that isn't a problem. We've tested this AJAX method of loading CSS/JS in IE, Firefox, Safari, etc... so it definitely should be good to go.
Shotster replied on at Permalink Reply
Shotster
> It sounded like CSS and/or JS wasn't loading through
> edit() addHeaderItem()

That's precisely the problem. The method is running, but the JS is not being added to the head. I'm using Safari 5.0.1.

>I just meant to say that that might because a browser wasn't
> happy loading it through AJAX

I'll try Firefox.

-Steve
cherrycake replied on at Permalink Reply
cherrycake
i might be off but the way you're describing it, it sounds like you can't be sure that it hasn't loaded. the document head doesn't show it since it's loaded asynchronously.

my suggestion is to download the firebug addon to firefox if you dont already have it and check the console tab. it will list all asynchronous calls made by your browser and also show you a dynamically updated html source output.

if you truly are sure that it isn't loaded, then i'm lost too. :)
Shotster replied on at Permalink Reply
Shotster
Thanks, cherrycake. Understood. I'm using Safari's DOM viewer and debugging tools which show elements loaded via XHR. I can see the call to ccm_addHeaderItem in the embedded script of edit_block_popup.php. I'll have to investigate to see why the script reference is not being added to the head.

-Steve
Shotster replied on at Permalink Reply
Shotster
> I'll have to investigate to see why the script
> reference is not being added to the head.

The reason, it turns out, is because jQuery is performing some magic behind the scenes. Even though, syntactically, it "appears" the script is being appended to the document head, jQuery actually just executes it but does not add the script element to the document head.

This explains my confusion as to why link elements (stylesheets) added in like manner DO appear in the DOM when appended to the document head, while script elements do not. The same syntax is used for each. Within the ccm_addHeaderItem() function of ccm.base.js, you'll see the following lines...

$('head').append('<link rel="stylesheet" type="text/css" href="' + item + '?ts=' + new Date().getTime() + '" />');
$('head').append('<script type="text/javascript" src="' + item + '?ts=' + new Date().getTime() + '"></script>');

As noted, stylesheets appear within the DOM after appending them to the head. This can be seen using browser debugging and DOM inspection tools (like Firebug for Firefox), while the script elements do not.

In fact, I found a minor bug in the ccm_addHeaderItem() function with regard to adding stylesheets. The duplicate suppression was not working, and the same stylesheet would get inserted into the DOM multiple times as blocks were added/edited on the same page. The original function is as follows...

ccm_addHeaderItem = function(item, type) {
   var doLoad = true;
   if (type == 'CSS') {
      for (i = 0; i < document.styleSheets.length; i++) {
         ss = document.styleSheets[i];         
         if (ss.href == item) {
            doLoad = false;
            break;
         }
      }
   } else if (type == 'JAVASCRIPT') {
      $("script").each(function(i, obj) {
         var src = $(obj).attr('src');
         if (src == item) {
            doLoad = false;
Viewing 15 lines of 29 lines. View entire code block.

A more streamlined version with duplicate suppression that actually works is as follows...

ccm_addHeaderItem = function(item, type) {
   if (type == 'CSS') {
      if (!($('head').children('link[href*=' + item + ']').length)) {
         $('head').append('<link rel="stylesheet" type="text/css" href="' + item + '?ts=' + new Date().getTime() + '" />');
      }
   } else if (type == 'JAVASCRIPT') {
      if (!($('head').children('script[src*=' + item + ']').length)) {
         $('head').append('<script type="text/javascript" src="' + item + '?ts=' + new Date().getTime() + '"></script>');
      }
   }
}

The check for existing scripts in the head really doesn't matter because, as noted above, jQuery doesn't actually append the script element; but at least it will work if jQuery's behavior is ever changed or if the script is already there by some other mechanism.

-Steve
Shotster replied on at Permalink Reply 1 Attachment
Shotster
For whatever reason, I could not attach a file to my last post, so here's another attempt. Attached is a patch if anyone is interested.

-Steve
andrew replied on at Permalink Reply
andrew
Ah - that makes sense. I do recall jQuery doing some magic when it attempted to load scripts and doing so differently.

Your patch is more elegant than the current code - it will likely get added back into the core.