-
Notifications
You must be signed in to change notification settings - Fork 2.4k
prevent generation of new hash on form submit #5069
Comments
@johnbender - Is this a solution for #3227 ? |
@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? |
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. 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 Thanks for the extended example. This appears to be working for us now as well, but will continue to test. |
@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. |
@dcarrith glad it worked, thank you for update it to the current branch. |
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. |
@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. |
@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? |
@arschmitz sound like doing so may end up closing a lot of issues. |
We've decided that we'll try to squeeze this in for 1.5. |
👍 |
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.
Just in case you are interested in add this option.
The text was updated successfully, but these errors were encountered: