prevent generation of new hash on form submit #5069

Open
dahool opened this Issue Sep 22, 2012 · 13 comments

Comments

Projects
None yet
6 participants
@dahool

dahool commented Sep 22, 2012

similar to #3226

I have a page with a form popup to apply filters to the current page (self submit), currently, the page is added to the history, so hitting the back button return to the same page.

I added a new attribute and a simply hack to skip the creation of a new hash when needed.

--- jquery.mobile.navigation_orig.js    Sat Sep 22 19:48:59 2012
+++ jquery.mobile.navigation.js Sat Sep 22 19:52:36 2012
@@ -1284,9 +1284,12 @@
                return;
            }

+           var updateHistory = !$this.is(":jqmData(history='false')");
+
            $.mobile.changePage(
                url,
                {
+                   changeHash: updateHistory,
                    type:       type && type.length && type.toLowerCase() || "get",
                    data:       $this.serialize(),
                    transition: $this.jqmData( "transition" ),

Just in case you are interested in add this option.

@jaspermdegroot

This comment has been minimized.

Show comment Hide comment
@jaspermdegroot

jaspermdegroot Dec 16, 2012

Member

@johnbender - Is this a solution for #3227 ?

Member

jaspermdegroot commented Dec 16, 2012

@johnbender - Is this a solution for #3227 ?

@atdev2

This comment has been minimized.

Show comment Hide comment
@atdev2

atdev2 Feb 13, 2013

@dahool We tried this on 1.2.0 and the latest RC release and it did not seem to work. What is your configuration like?

atdev2 commented Feb 13, 2013

@dahool We tried this on 1.2.0 and the latest RC release and it did not seem to work. What is your configuration like?

@dahool

This comment has been minimized.

Show comment Hide comment
@dahool

dahool Feb 13, 2013

mmm, not exactly sure what you mean with configuration ... this is the page I had issues until I applied this patch. I'm using jqm 1.2.0 and jq 1.8.2.
The last div #dateFilter is a popup with a form posting to the same page, using data-history="false".

I can say it works, because I'm using it and it didn't work without this patch.

<div data-role="page" data-cache="never">
<div data-role="header" data-theme="e" data-position="fixed">
        <a href="{% url mobile:expenses %}" data-icon="back" data-theme="b" data-rel="back">Volver</a>
        <h1>Listado</h1>
        <a href="{% url mobile:expenses_add %}" data-icon="add" data-theme="f">Nuevo</a>
</div><!-- /header -->

<div data-role="content" data-return="{% url mobile:expenses_list %}">
        <ul data-role="listview" data-inset="true">
            {% regroup list by date as exp_group %}
            {% for group in exp_group %}
                <li data-role="list-divider">{% ifequal today group.grouper %}Hoy{% else %}{{group.grouper}}{% endifequal %}<span class="ui-li-count">${{group.list|sumlist:"amount"|floatformat:2}}</span></li>
                {% for item in group.list %}
                <li swipe-options='{"direction": "left", "buttons": [{"style": "r", "value": "Borrar", "href": "javascript:confirmSingleAction(\"{% url expenses_delete %}\",\"{{item.id}}\")"},{"style": "e", "value": "Editar", "href": "{% url mobile:expenses_edit item.id %}"}]}'>
                    <div>
                        <h3>{{item.text}} ({{item.subCategory.category.name}})</h3>
                        <p>{{item.paymentType.name}}</p>
                        <span class="ui-li-aside">${{item.amount|floatformat:2}}</span>
                    </div>
                </li>
                {% endfor %}

            {% endfor %}
        </ul>
</div><!-- /content -->

<div data-role="footer" class="ui-bar" data-id="footer" data-position="fixed" data-tap-toggle="false">
<div class="ui-grid-a">
<div class="ui-block-a"><a href="{% url mobile:home %}" data-role="button" data-icon="home" data-iconpos="notext" data-mini="true"></a></div>
<div class="ui-block-b"><a data-theme="a" href="#dateFilter" data-rel="popup" data-role="button" data-corners="false" data-iconpos="right" data-mini="true" data-icon="gear" data-inline="true">{{filterStart|date:"d-m-Y"}} | {{filterEnd|date:"d-m-Y"}}</a></div> 
</div>  
</div>

<div data-role="popup" id="dateFilter" popup-keep-open data-theme="a" class="ui-corner-all" data-history="false">
<a href="#" data-rel="back" data-role="button" data-theme="a" data-icon="delete" data-iconpos="notext" class="ui-btn-right">Cerrar</a>
<form method="post" action="{% url mobile:expenses_list %}" data-history="false">
{% csrf_token %}
<div style="padding:10px 20px;">
              <label for="fromDate">Desde:</label>
              <input type="date" data-role="datebox" value="{{filterStart|date:"d/m/Y"}}" name="fromDate" id="fromDate" />
              <label for="toDate">Hasta:</label>
              <input type="date" data-role="datebox" value="{{filterEnd|date:"d/m/Y"}}" name="toDate" id="toDate" />
<button type="submit" data-theme="b" data-icon="check">Aplicar</button>
</div>
</form>
</div>

dahool commented Feb 13, 2013

mmm, not exactly sure what you mean with configuration ... this is the page I had issues until I applied this patch. I'm using jqm 1.2.0 and jq 1.8.2.
The last div #dateFilter is a popup with a form posting to the same page, using data-history="false".

I can say it works, because I'm using it and it didn't work without this patch.

<div data-role="page" data-cache="never">
<div data-role="header" data-theme="e" data-position="fixed">
        <a href="{% url mobile:expenses %}" data-icon="back" data-theme="b" data-rel="back">Volver</a>
        <h1>Listado</h1>
        <a href="{% url mobile:expenses_add %}" data-icon="add" data-theme="f">Nuevo</a>
</div><!-- /header -->

<div data-role="content" data-return="{% url mobile:expenses_list %}">
        <ul data-role="listview" data-inset="true">
            {% regroup list by date as exp_group %}
            {% for group in exp_group %}
                <li data-role="list-divider">{% ifequal today group.grouper %}Hoy{% else %}{{group.grouper}}{% endifequal %}<span class="ui-li-count">${{group.list|sumlist:"amount"|floatformat:2}}</span></li>
                {% for item in group.list %}
                <li swipe-options='{"direction": "left", "buttons": [{"style": "r", "value": "Borrar", "href": "javascript:confirmSingleAction(\"{% url expenses_delete %}\",\"{{item.id}}\")"},{"style": "e", "value": "Editar", "href": "{% url mobile:expenses_edit item.id %}"}]}'>
                    <div>
                        <h3>{{item.text}} ({{item.subCategory.category.name}})</h3>
                        <p>{{item.paymentType.name}}</p>
                        <span class="ui-li-aside">${{item.amount|floatformat:2}}</span>
                    </div>
                </li>
                {% endfor %}

            {% endfor %}
        </ul>
</div><!-- /content -->

<div data-role="footer" class="ui-bar" data-id="footer" data-position="fixed" data-tap-toggle="false">
<div class="ui-grid-a">
<div class="ui-block-a"><a href="{% url mobile:home %}" data-role="button" data-icon="home" data-iconpos="notext" data-mini="true"></a></div>
<div class="ui-block-b"><a data-theme="a" href="#dateFilter" data-rel="popup" data-role="button" data-corners="false" data-iconpos="right" data-mini="true" data-icon="gear" data-inline="true">{{filterStart|date:"d-m-Y"}} | {{filterEnd|date:"d-m-Y"}}</a></div> 
</div>  
</div>

<div data-role="popup" id="dateFilter" popup-keep-open data-theme="a" class="ui-corner-all" data-history="false">
<a href="#" data-rel="back" data-role="button" data-theme="a" data-icon="delete" data-iconpos="notext" class="ui-btn-right">Cerrar</a>
<form method="post" action="{% url mobile:expenses_list %}" data-history="false">
{% csrf_token %}
<div style="padding:10px 20px;">
              <label for="fromDate">Desde:</label>
              <input type="date" data-role="datebox" value="{{filterStart|date:"d/m/Y"}}" name="fromDate" id="fromDate" />
              <label for="toDate">Hasta:</label>
              <input type="date" data-role="datebox" value="{{filterEnd|date:"d/m/Y"}}" name="toDate" id="toDate" />
<button type="submit" data-theme="b" data-icon="check">Aplicar</button>
</div>
</form>
</div>
@atdev2

This comment has been minimized.

Show comment Hide comment
@atdev2

atdev2 Feb 13, 2013

@dahool Thanks for the extended example. This appears to be working for us now as well, but will continue to test.

atdev2 commented Feb 13, 2013

@dahool Thanks for the extended example. This appears to be working for us now as well, but will continue to test.

@dcarrith

This comment has been minimized.

Show comment Hide comment
@dcarrith

dcarrith Aug 7, 2013

Contributor

@dahool - brilliant!

I came across this post while researching an apparent issue between JQM Dialogs and PRG (Post/Redirect/Get) patterns in general. In my application in particular, I have a dialog that displays an add/edit form. The add/edit form is POSTed to itself to be validated. It is then redirected to a GET route where it displays a success message (or validation errors) and allows for further edits. I updated the code snippet above to be compatible with the 1.3-stable branch and also modified it to be a one-liner.

index ade51fa..0850405 100644
--- a/js/jquery.mobile.navigation.js
+++ b/js/jquery.mobile.navigation.js
@@ -1070,6 +1070,7 @@ define( [
                                                data:           $.param( formData ),
                                                transition:     $form.jqmData( "transition" ),
                                                reverse:        $form.jqmData( "direction" ) === "reverse",
+                                               changeHash:     $form.is( ":jqmData(history='false')" ) ? false : true,
                                                reloadPage:     true
                                        }
                                };

That code change, combined with a data-history="false" on the form element, fixes the issue I was seeing (basically the same as #3227 and #3226) and it doesn't seem to cause any issues in the rest of my application. Awesome, thanks @dahool!

In the current 1.3-stable branch (1.3.3-pre) it looks like 53 of the sequence-path1-path2-dialog-hash-key-tests are failing (with or without the above change in place). But, I was able to run all the other tests successfully and none failed.

Contributor

dcarrith commented Aug 7, 2013

@dahool - brilliant!

I came across this post while researching an apparent issue between JQM Dialogs and PRG (Post/Redirect/Get) patterns in general. In my application in particular, I have a dialog that displays an add/edit form. The add/edit form is POSTed to itself to be validated. It is then redirected to a GET route where it displays a success message (or validation errors) and allows for further edits. I updated the code snippet above to be compatible with the 1.3-stable branch and also modified it to be a one-liner.

index ade51fa..0850405 100644
--- a/js/jquery.mobile.navigation.js
+++ b/js/jquery.mobile.navigation.js
@@ -1070,6 +1070,7 @@ define( [
                                                data:           $.param( formData ),
                                                transition:     $form.jqmData( "transition" ),
                                                reverse:        $form.jqmData( "direction" ) === "reverse",
+                                               changeHash:     $form.is( ":jqmData(history='false')" ) ? false : true,
                                                reloadPage:     true
                                        }
                                };

That code change, combined with a data-history="false" on the form element, fixes the issue I was seeing (basically the same as #3227 and #3226) and it doesn't seem to cause any issues in the rest of my application. Awesome, thanks @dahool!

In the current 1.3-stable branch (1.3.3-pre) it looks like 53 of the sequence-path1-path2-dialog-hash-key-tests are failing (with or without the above change in place). But, I was able to run all the other tests successfully and none failed.

@dahool

This comment has been minimized.

Show comment Hide comment
@dahool

dahool Aug 7, 2013

@dcarrith glad it worked, thank you for update it to the current branch.

dahool commented Aug 7, 2013

@dcarrith glad it worked, thank you for update it to the current branch.

@dcarrith

This comment has been minimized.

Show comment Hide comment
@dcarrith

dcarrith Aug 8, 2013

Contributor

It looks like JQM pages have the same issue with PRG patterns. So, it's not just with dialogs. With the above code fix in place, I added a data-history="false" on a form element in a data-role="page" div that was exhibiting a similar issue (manifesting in the form of needing to hit the cancel button - or back button - twice after saving the form in order to go back) and sure enough, it fixed it.

Contributor

dcarrith commented Aug 8, 2013

It looks like JQM pages have the same issue with PRG patterns. So, it's not just with dialogs. With the above code fix in place, I added a data-history="false" on a form element in a data-role="page" div that was exhibiting a similar issue (manifesting in the form of needing to hit the cancel button - or back button - twice after saving the form in order to go back) and sure enough, it fixed it.

@dcarrith

This comment has been minimized.

Show comment Hide comment
@dcarrith

dcarrith Aug 8, 2013

Contributor

@johnbender, @ugomobi, @toddparker - Is @dahool's approach to prevent generation of new hash on form submit still under consideration? My post above was the first activity on this issue or related issues #3226, #3227 or #2452 in about 6 months. I'm surprised that there aren't more people reporting issues like the ones mentioned in #3227, #3226 and #2452.

Contributor

dcarrith commented Aug 8, 2013

@johnbender, @ugomobi, @toddparker - Is @dahool's approach to prevent generation of new hash on form submit still under consideration? My post above was the first activity on this issue or related issues #3226, #3227 or #2452 in about 6 months. I'm surprised that there aren't more people reporting issues like the ones mentioned in #3227, #3226 and #2452.

@dcarrith

This comment has been minimized.

Show comment Hide comment
@dcarrith

dcarrith Aug 8, 2013

Contributor

I searched through the issues list with the keywords "form submit" and I think I found a few more related issues (or at least issues where someone commented randomly to report a similar thing): #708, #1577, and #1537. For #1537, take a look at @Savvkin's comment at the bottom.

Contributor

dcarrith commented Aug 8, 2013

I searched through the issues list with the keywords "form submit" and I think I found a few more related issues (or at least issues where someone commented randomly to report a similar thing): #708, #1577, and #1537. For #1537, take a look at @Savvkin's comment at the bottom.

@gabrielschulhof

This comment has been minimized.

Show comment Hide comment
@gabrielschulhof

gabrielschulhof Jun 10, 2014

Contributor

@arschmitz should we endorse this data-attribute? We already listen to several data-attributes present on the form. If turning off hash setting for the one request helps, should we support that?

Contributor

gabrielschulhof commented Jun 10, 2014

@arschmitz should we endorse this data-attribute? We already listen to several data-attributes present on the form. If turning off hash setting for the one request helps, should we support that?

@gabrielschulhof

This comment has been minimized.

Show comment Hide comment
@gabrielschulhof

gabrielschulhof Jun 10, 2014

Contributor

@arschmitz sound like doing so may end up closing a lot of issues.

Contributor

gabrielschulhof commented Jun 10, 2014

@arschmitz sound like doing so may end up closing a lot of issues.

@gabrielschulhof

This comment has been minimized.

Show comment Hide comment
@gabrielschulhof

gabrielschulhof Jul 9, 2015

Contributor

We've decided that we'll try to squeeze this in for 1.5.

Contributor

gabrielschulhof commented Jul 9, 2015

We've decided that we'll try to squeeze this in for 1.5.

@dcarrith

This comment has been minimized.

Show comment Hide comment
@dcarrith

dcarrith Jul 9, 2015

Contributor

👍

Contributor

dcarrith commented Jul 9, 2015

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment