Currently if you use one of the month raquo's to browse the calendar block, not only does the calendar block change, the whole page is refreshed, and set to the events overview page. The month raquo does not suggest navigation to another page, and the result is more disruptive than it needs to be.

With Drupal 4.7 (or 4.6 with Ajax.module) there could be an AJAX-style refresh of just the calendar.

CommentFileSizeAuthor
#27 eventblock.js__0.txt2.72 KBsnufkin
#26 ajaxblock_0.patch4.29 KBkilles@www.drop.org
#24 ajaxblock.patch3.29 KBkilles@www.drop.org
#21 eventblock.js_.txt2.75 KBsnufkin
#20 eventblock.patch4.34 KBsnufkin
#19 eventblock_ajax_0.patch4.05 KBsnufkin
#17 eventblock_0.js2.65 KBahoeben
#14 eventblock.js2.64 KBahoeben
#13 eventblock_ajax2.patch3.32 KBahoeben
#4 eventblock_ajax.patch3.92 KBahoeben

Comments

drewish’s picture

drewish commented

I'll save killes the trouble and suggest that a patch would be most welcome.

killes@www.drop.org’s picture

killes@www.drop.org commented
Version: 4.6.x-1.x-dev » 5.x-2.x-dev

Yep. Especially since I have absolutely no clue about Ajax. :p

markus_petrux’s picture

markus_petrux commented

You may want to check out this:
http://www.jonabad.com/livecalendar/

It's a WordPress plugin that exactly does this. A demo can be found at the very bottom of the page.

ahoeben’s picture

ahoeben commented
Status: Active » Needs work
StatusFileSize
new eventblock_ajax.patch3.92 KB

Took me a while, but it works (and degrades nicely).

Notes:

  • I only implemented AJAX refreshing of the block, not of a full event page. This makes most sense to me
  • Conversely, I add drupal.js only if the block is added to the page (drupal.js is required for AJAXy stuff). Is this the common practice?
  • Had to add a somewhat ugly <div> around the calender block. Does anyone have a better idea, that is theme independant?
    Is there a call I can make from inside a _block hook to know the id of the div the block gets put in?
amanuel’s picture

amanuel commented

Would be nice to move the JS out of the html (the onclick for example) to keep things nice and clean. Make the JS truly unobtrusive (http://www.onlinetools.org/articles/unobtrusivejavascript/).

Otherwise it looks good.

ahoeben’s picture

ahoeben commented

Answering my own third question: *If* the user has not changed the default theming for a block, the calendar block should always be inside a div with id "block-event-0".

In order to remove the ugly <div> from the patch, I'ld have to either refresh the entire block (including the block title, going halfway through the theming system), or find the <div> with class = "content" in the block <div>, again provided the user has not changed the default theming for blocks.

Would that be worth the effort, or do we want to keep the hack? We could rename the added <div> to block-event-0-content to get in line with the (default) block naming.

scroogie’s picture

scroogie commented

For me the work-around sounds more like a hack than the extra-diff. Like the change though, hope this gets committed.

scroogie’s picture

scroogie commented

I meant extra-div of course.

markus_petrux’s picture

markus_petrux commented

I also think you could move all javascript to a separate file. In this file you could create an onload event handler, and here searchn for the calendar block, attach the onclick events, etc.

I would also add a small animation (similar to the one used in autocomplete fields) to be shown while waiting for the AJAX method to process the request and rebuild the block.

markus_petrux’s picture

markus_petrux commented

I forgot to add that maybe the javascript part could be made as a reusable component, so other calendar-like modules could use the same method.

ahoeben’s picture

ahoeben commented

I'll be implementing the javascript suggestions later this week (thanks for the hints), unless someone beats me to it.

It would indeed be usefull to make what I do in js reuable for other other (calendar) modules such as the archive module, but I think that should be true for the full calendar block (not just the javascript). But ofcourse, that's a bigger task...

About my <div> hack... I thought of a way to make this <div> itself themeable. More about that later.

Thox’s picture

Thox commented

If you make a "loading" widget then we've got the progress bar already and the little spinning icon.

AFAIK, all JS in Drupal is currently in external files (e.g. upload.js). This would be a little cleaner in my opinion, but not really essential.

Lastly, I've not got event module around to see, but I'm assuming that you haven't declared $file - so in fact you're probably outputting an extra useless script tag in the HTML. This might be better off as drupal_add_js('misc/drupal.js');, although that seems just as bad.

ahoeben’s picture

ahoeben commented
StatusFileSize
new eventblock_ajax2.patch3.32 KB

New patch, externalises all javascript in an additional javascript file 'eventblock.js' (see next post)
This is a separate file from event.js, since eventblock is for the block, and event.js for the full page event. The block may be on pages where the full page calendar is not, and vice versa.

ahoeben’s picture

ahoeben commented
StatusFileSize
new eventblock.js2.64 KB

Here's the eventblock.js for the patch above.

The blockupdater function could eventually grow into it's own file living in /misc, I have written it so it can be used to update other blocks as well.

ahoeben’s picture

ahoeben commented

Left to do:

  • IE on windows does not properly report offsetheight, so there's a bit of jumpiness going on
  • Firefox is not showing the cancel link (odd...)
markus_petrux’s picture

markus_petrux commented

For the firefox issue: Have you tried createElement("a") instead of createElement("A") ?

ahoeben’s picture

ahoeben commented
StatusFileSize
new eventblock_0.js2.65 KB

No, it was missing support for element.innerText.

New version of eventblock.js has a cancel button in Firefox, and removes the 'Updating block' caption since it annoyed me (and serves no real purpose; what else could be going on?)

killes@www.drop.org’s picture

killes@www.drop.org commented

It's a shame I never looked at this.

Could this be reworked into using jquery?

snufkin’s picture

snufkin commented
StatusFileSize
new eventblock_ajax_0.patch4.05 KB

updated the patch for the actual 4.7 (no real change, just patch update, will try to update for HEAD)

snufkin’s picture

snufkin commented
StatusFileSize
new eventblock.patch4.34 KB

cant believe its been only one day. my first work on AJAX stuff, voila.
patch for the module and theme in this post, javascript file in the next one.

snufkin’s picture

snufkin commented
StatusFileSize
new eventblock.js_.txt2.75 KB

javascript port for HEAD with jquery.

ahoeben’s picture

ahoeben commented

It would be great if the block update mechanism could somehow be abstracted into something that could eventually be moved to core. That's why I originally chose a 'generic' name in the javascript (blockUpdater instead of eventBlockUpdater), but that might actually not be a smart thing to do if this actually gets moved to core or a generic contrib module.

ahoeben’s picture

ahoeben commented

Updated patch looks good, but have not tested (I currently have no 5.x site with event.module)

killes@www.drop.org’s picture

killes@www.drop.org commented
StatusFileSize
new ajaxblock.patch3.29 KB

I tried it, one chunk of the patch failed, I fixed that manually (and attach the patch here). However, I am not able to discover any evidence of Ajaxification.

Ok, found the problem: The vevntblock.js file was not where the patch expected it to be, I've fixed that. However, there is still a problem: The page is still changed to the general calendar. I think the idea is to not change the rest of the page, but only reload the event block.

snufkin’s picture

snufkin commented

killes: you removed the event.theme part from the patch, that is required, otherwise it considers the click as normal navigation.

killes@www.drop.org’s picture

killes@www.drop.org commented
StatusFileSize
new ajaxblock_0.patch4.29 KB

event.theme included again.

I had used the patcheed version on my test setup.

snufkin’s picture

snufkin commented
StatusFileSize
new eventblock.js__0.txt2.72 KB

after an incredibly long battle with jQuery, here it is: the (supposed) eventblock.js for Drupal 5
There is a glitch I have no clue how to fix: the cancel button sometimes doesnt stop the process correctly, as if it were disregarding it.

killes@www.drop.org’s picture

killes@www.drop.org commented
Status: Needs work » Fixed

I've commited this to the HEAD branch. If there are no complaints, I'll port it to the Drupal 5 branch.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)
baloneysammitch’s picture

baloneysammitch commented
Title: Use AJAX updates for calendar block » Use jQuery 1.2.2 AJAX updates for calendar block
Status: Closed (fixed) » Active

I updated to jQuery 1.2 and the code no longer works. It seemed to not like href():
$(this).href() is not a funciton

So I replaced href() with attr("href") and it seemed to at least get past that point. I'm lost as to why it isn't updating the block though.

japerry’s picture

japerry
Location KOMK
commented
Status: Active » Closed (outdated)

Event for Drupal 8 is unrelated to older versions. If an issue similar to this one exists, please open a new issue with the 8.x branch.