Skip to content
This repository was archived by the owner on Oct 8, 2021. It is now read-only.

prevent generation of new hash on form submit #5069

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

prevent generation of new hash on form submit #5069

dahool opened this issue Sep 22, 2012 · 13 comments

Comments

@dahool
Copy link

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
Copy link
Contributor

@johnbender - Is this a solution for #3227 ?

@bjohnson045
Copy link

@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
Copy link
Author

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>

@bjohnson045
Copy link

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

@dcarrith
Copy link
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
Copy link
Author

dahool commented Aug 7, 2013

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

@dcarrith
Copy link
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
Copy link
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
Copy link
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
Copy link

@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
Copy link

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

@gabrielschulhof
Copy link

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

@dcarrith
Copy link
Contributor

dcarrith commented Jul 9, 2015

👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants