new working ajax_quiz: request for testing of my ajax_quiz proposition

Oh, sorry, the attachment apparently went away when I was trying to edit the list of "known issues". Here it is again.

Please bear with me, it's the first time I do such stuff. So, honestly, I didn't watch out for disappearing attachments ;-)

This is the next version, which should work with a CVS checkout of quiz-6.x-4.0-dev. I did as described here: http://drupal.org/node/26481/cvs-instructions/DRUPAL-6--4

For comments, see next comment. (I don't wanna loose that file again ;-)

"Line 34": it now uses 'access quiz' permission.
"Line 122": will be solved after you saw it working. ;-)

Using arg(1) for fetching the quiz nid would work if you display the quiz as a stand-alone main page content, but not inside of views and panels (which have other URLs, of course). But quiz-inside-views&panels is the reason why you would ajaxify quiz in the first place: in order to display it beside other content which shall not go away on a page refresh. Or, as it is the case with my client, the other content can not re-appear on page reload, because it is also ajaxified stuff.

So from the point of view of AJAX, I think it is not a good thing to make quiz more and more dependent on the URL, as it happened at least in 3 ways I know of currently:
* by making quiz taking a MENU_LOCAL_TASK (I had to work around that by starting to use a customized template_preprocess_views_view_row_node().)
* by using menu_get_object(), at least in "quiz taking" contexts (This one I also solved in the customized template_preprocess_views_view_row_node().)
* by letting _quiz_is_taking_context() do a comparison for arg(2) == 'take' as of the current 4.0-dev version. I think I will achieve to fool even arg(2) into thinking the "right" thing, but "fooling" is not a clean concept to be easily understood by fellow developers. BTW, the old _quiz_is_taking_context() "just worked".

Just for the record, here is my customized template_preprocess_views_view_row_node():

function mytheme_preprocess_views_view_row_node(&$vars) {
  $options = $vars['options'];

  // Make sure the variables are defined.
  $vars['node'] = '';
  $vars['comments'] = '';

  $nid = $vars['row']->{$vars['field_alias']};
  if (!is_numeric($nid)) {
    return;
  }

  $node = node_load($nid);

  if (empty($node)) {
    return;
  }

  $node->view = $vars['view'];
  $node->build_mode = ($options['build_mode'] == 'teaser' || $options['build_mode'] == 'full') ? NODE_BUILD_NORMAL : $options['build_mode'];
  if ('quiz' == $node->type) {
    $old_router_item = menu_get_item(); // Preserve current setting.
    menu_set_item($_GET['q'], menu_get_item('node/' . $nid . '/take')); // Fool all the menu_get_object()-calls inside of quiz into thinking the "right" thing.
    $vars['node'] = quiz_take($node, NULL); // "Take" quiz instead of just displaying the node.
    menu_set_item($_GET['q'], $old_router_item); // Restore old setting because we are currently inside a view and who knows for what else the old setting has to be used.
  } 
  else {
    $vars['node'] = node_view($node, $options['build_mode'] == 'teaser', FALSE, $options['links']);
  }

  if (!empty($options['comments']) && function_exists('comment_render')) {
    $vars['comments'] = comment_render($node);
  }
}

[thinking pause ...] Ha! Got it! If I will be able to "fool" arg(2), we also can use arg(1) instead of "Line 122".

But honestly, I'd *love* to get rid of the customized template_preprocess_views_view_row_node(), because I think this will be an entry barrier for other users who wish to ajaxify their quizzes.

Regarding the dependency on "ajax_load": getting rid of this dependency essentially means duplicating "ajax_load"s code, which I'm only reluctant to do: http://en.wikipedia.org/wiki/DRY But if you request so, I will do it. Maybe I get around to conditionally use either my integrated duplicate or another "ajax_load", if installed and of a superior version. I believe most AJAX-heavy users will have "ajax_load" installed, anyway.

Regards,
raphaelhuefner

LOL! The thought of "[DRY] applies best for organizations/programmers who are in control of all the[ir] code" and the words "third party software" struck a bell: One also could interpret DRY as "Don't repeat *yourself* ... but most certainly *do* repeat others!" Strikingly logical, isn't it? :-D

Well, ice broken. I'll try to integrate it. Even if it's only for the fun of playing on words ... ;-)

Regarding #7, point 1: This sounds very good, I will try that. Most of my client's quizzes have introductory texts anyway and I can even think of automatically submitting the "Start"-button if the module user wishes to bypass such "introductory texts". If I am right, this could get us rid of the _preprocess_views_view_row_node(&$vars) entirely. (It seems I kept on ajaxifying the "Start"-button out of my sight and therefore out of my mind. Thanks for re"mind"ing me. ;-)

@ Point 2: To me, this sounds like a major restructuring, which could get in the way of your plans for the next 4.0-rcX. I would suggest postponing that to maybe 4.1 or so. But I'd like to keep having it considered for the future. For the time being, I would go with "fooling" just to get 4.0 out of the door soon. (My next "attack vector" is replacing $_GET['q'] with "node/123/take" just before calling quiz_take() and reverting it back just in the next line after calling. I hope it works.)

Regards,
raphaelhuefner

@ Point 2: No, it should not be necessary to solve this to get rid of _preprocess_views_view_row_node(&$vars), if I'm not completely mistaken about what I learned about Drupal so far. But I'm still prone to the occasional surprise.

Concerning "ajax_load": We will grok the whole module, not only things we need, just because we need the whole module. It does only this one thing, in the best way I know of so far. It doesn't do anything else we could leave out from integration. And customizing amounts only to renaming all the module functions in order to avoid namespace conflicts, just in case the user has the "original" installed.
One more thing, not every quiz user would depend on it, only users who want to ajaxify their quizzes. It's the same as with the other quiz dependencies: For example, as long as I don't wish to do quiz statistics, I won't need "chart".

BTW, I will be "away from keyboard" from 5th of February until 20th of February. Let's see if I get it working before!

@ #12: I did my 4.0-dev version without views or panels, just for you to see it working. Well, epic FAIL. Lets see how I get to reproduce this error.

One first idea for solving: Please disable ajax_quiz_vc before going from ajax_quiz_vc-6.x-4.0-beta3 to ajax_quiz_vc-6.x-4.0-dev and then re-enable the module, because I did change the path of the MENU_CALLBACK to match that arg(2). I believe Drupal caches the menu paths? In my understanding, hook_menu() is only executed on enabling a module, is this correct?

Re #15: Now I got it, finally. "main quiz module" is not the "quiz module suite". I'll see into integrating, but first things first: You didn't see ajax_quiz_vc working once yet, right? This still nags me most.

Re #16: I'm eager to know which URL it is redirecting to, is it "/node/123/take" or "/node/123/take/ajax"? And is this redirecting error happening to the main page or to the AJAX request? For AJAX and JS development, I almost always have to rely on http://getfirebug.com/ to see "whats really happening".

Here is version 4.0-dev1 [sic!]

Please disable the module before update, and re-enable it after update, since I changed the MENU_CALLBACK path again.

4.0-dev1 does not yet address #20 or #17, but finally I got rid of _preprocess_views_view_row_node(&$vars) and of debug_backtrace(). Phew!

It shall work in direkt node_view and inside panels&views, too.

Just press "Start Quiz".

I just updated from CVS DRUPAL-6--4, and there seems to be something wrong with all those menu_get_object('quiz_type_access')-calls inside quiz, they return NULL instead of the quiz node, even if I disable ajax_quiz_vc. When I dump the menu router item returned by menu_get_item() under path "node/123/take", it has no "quiz_type_access_load" in its "load_functions"-array.

I believe this is a bug inside of quiz, because one symptom of this is a missing "Back"-button, even in non-AJAX (disabled ajax_quiz_vc) quiz taking. This can be seen in quiz_question.module @ line 168:

  $quiz = menu_get_object('quiz_type_access');
  if (!empty($quiz->backwards_navigation) && !empty($node->question_number)) {
    $form['back'] = array(
      '#type' => 'submit',
      '#value' => t('Back'),
    );
  }

This menu_get_object('quiz_type_access')-call returns NULL and thus no Back-button gets rendered.

Shall I open a new issue for that?

Regards,
raphaelhuefner

Re #23: I opened a new issue: #703682: menu_get_object('quiz_type_access') returns NULL on paths like "/node/123/take"

I can make the Back-button re-appear by manipulating my fake menu router item like this:

  $new_router_item = menu_get_item($fake_get_q);
  $new_router_item['load_functions'][1] = 'quiz_type_access_load';
  menu_set_item($old_get_q, $new_router_item);
  menu_set_item($fake_get_q, $new_router_item);

Regards,
raphaelhuefner

Re #17 and #20: I tried to reproduce both, #17 "jumping back to square one after quiz direction" and #20 "take tab confusion", but to no avail. Would you mind sending me a complete code-dump and a complete DB-dump (via mysqldump -h127.0.0.1 -P3306 -udbuser -pdbpass dbname --default-character-set=utf8 --no-create-db --routines --triggers | bzip2 > export.sql.bz2) of a setup where these errors occur at your site?

Regards,
raphaelhuefner

I'm away from keyboard until 20th of February. So long, good luck!

Hi @falcon,

sorry for being late, I was busy getting the back-log done which accumulated during my vacation.

As for the progress: I need your cooperation to reproduce the bugs you mentioned in #27. I do not achieve to reproduce them on my own.

The only idea I have so far is to give you the code-dump and DB-dump of my ajax_quiz_vc-testbed (pretty much only a clean Drupal 6.15 with current versions of the modules ajax_load, ajax_quiz_vc, autoload, ctools, panels, quiz-6.x-4.0-dev [recent CVS checkout] and views), and you "install the bugs" and send it back to me.

I will set up a public installation of this testbed and post the URL here.

The testbed installation can be found here:

http://ajax.quiz.drupal.raphaelhuefner.com/

user: admin
pass: ajax_quiz_vc2010

code-dump:
http://ajax.quiz.drupal.raphaelhuefner.com/sites/default/files/aqtest.tgz

DB-dump:
http://ajax.quiz.drupal.raphaelhuefner.com/sites/default/files/aqtest.sq...

OK, let's put this on hold until after finishing 4.0.

For the record while being "on hold": I'm still stumped on how to reproduce the bugs described in #20 and #27, so I take the liberty to set this issue back to "needs review", hoping to get input from somebody else, as I guess that you might be too busy as the quiz module maintainer, now, especially during 4.0 release preparations.

Bug fix: Avoid to call drupal_add_js($settings, 'setting') twice, as the duplicated data would get merged into an array instead of overwriting the data of the first call. Effect: The throbber shows up again.