Giters

azicchetti / jquerymobile-router

A router/controller for jquery mobile. Also adds support for client-side parameters in the hash part of the url. The routes handles regexp based routes. This plugin can be used alone or (better) with Backbone.js or Spine.js, because it's originally meant to replace their router with something integrated with jQM.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Chaining Dialogs

opened this issue · comments

commented

I open a dialog like so:

var $page = $('#login');
$.mobile.changePage($page, {role: 'dialog', hashChange: false, transition: 'slidedown'});

which works as expected. When opening another dialog from the first one in the click event handler like so:

var $page = $('#signup');
$.mobile.changePage($page, {role: 'dialog', hashChange: false, transition: 'slidedown'});

it seem to break the router, I can't go anywhere from here.

Can't see any exceptions or errors thrown in Chrome dev tools.

commented

Hi,
in a super-simple test it seems to work, I think I'll need a proper example.

A couple of questions:

  • why are you using a jquery object instead of a simple string in the changePage call?
  • the right option property to preserve the current hash is: changeHash: false
  • is there a particular reason you're doing this programmatically?

Cheers,
Andrea

commented

Hi Andrea,

to answer your questions:

  • it seems to make no difference whether you provide a backbone view object or a simple string to changePage call.
  • my bad
  • I have changed that, since on the second dialog there is no reason to do it programmatically.

However, non of these caused my issue, but simply a duplicated id on an <a> tag.

Now, the second dialog opens from the first one. The only issue I couldn't fix yet is that the second dialog's ui doesn't enhance even after calling

$(backboneView.el).trigger("create");

However, routing works as expected.

commented

To wrap this up, there was nothing wrong with routing. However, chaining dialogs seem to work either only with the standard implementation or programmatically. Mixing both approaches causes the second dialog not being enhanced properly.

commented

Uhm, I thought I saw everything that jQM could do to drive a developer crazy, I'm glad I missed this one...

I can't seem to be able to reproduce this strange behavior, it would be funny to see a test case (and maybe report the issue to jQM guys).
It's quite strange because jQM should enhance the page when it's first visited, regardless of the source of the page change.