The component is not within the form, but uses alpinejs to update the actual hidden widget that is in the form, and then submits it. This works without issues.
The problem I have is the if-condition breaking. While the form is unbound the condition scope_id == search_form.scope.value is True and the text shows DEBUG: All | 0 | 0
After clicking on any of the other choices, and after the form is submitted, I can confirm that the website shows DEBUG: Print | 1 | 1, which means that {% if scope_id == search_form.scope.value %} (or 1 == 1) should be True, but it isn’t. Why?
If you are rendering this HTML fragment in Django, keep in mind that all template rendering occurs in the server and not in the browser.
Your {% if ...%} block is evaluated by Django at the time the template is being rendered. By the time it has been sent to the browser, that tag has been resolved and does not exist in the rendered html.
I suggest you examine the rendered html in your browser’s developer tools to see what has been rendered and is being processed in the browser.
Hi Ken, I am aware the rendering happens on the server. I don’t understand the rest of your comment. Did you read the code correctly?
Edit: Not trying to be confrontational, I just don’t understand what direction that response is going, or how it applies to my code. Thanks for your help!
Yes, I did that. I did include that in my question:
By text I mean that part of the template where it is written: DEBUG: {{ scope }} | {{ scope_id }} | {{ search_form.scope.value }}. It’s all rendered on the server. So if this results in DEBUG: Print | 1 | 1, why is {% if scope_id == search_form.scope.value %} then False?
What does the view look like that is processing all this?
Actually, I’m going to guess that this is a data-type issue. Your choices are defined with integer values, but I’m going to guess at some point along this chain, something is converting that to a string - and so the comparison is failing.
The only attribute of the data in a bound form that is supposed to be normalized to the proper type is cleaned_data. All data submitted (bound) to the form coming from the client must be strings. Form POST data doesn’t have any other type. Note that POST data doesn’t quote strings, it’s submitted as name=value. When Django receives it, it can’t do anything other than accept it as a string.
Looking at the BoundField code, it appears that the BoundField value is the initial value (the 0 int in your case) if the form is not bound, or the value from POST data (which is always a string) when form is bound.
So the comparison with integers (from the choices) works when form is not bound, but cannot work on a bound form.
If you want the comparison to work in all cases, you have to convert values (from choices and bound field value) to str before doing comparison. E.g.
{% if scope_id|stringformat:"s" == search_form.scope.value|stringformat:"s" %}
It does not seem very straight forward, but I think this is the way BoundFields work.
Using TypedChoiceField does not help here, even if I think this is still relevant to retrieve the correct type for scope in your view after form validation.
Yeah, I learned that, too. Value is holding the raw input, which is why it is a string. I’m using a form to manage a table with search, filtering, more filtering and pagination, because that’s the only way of passing multiple parameters in a request, without adding dozens of lines of complex code to my view and template. But that also means that I also need the data of invalid form. If the search query does not meet the minimum of 3 chars, I still want the user to go to the next page. Hence why I need the value.
Overall, these kind of scenarios feel extremely complicated to implement, but on the other hand are nothing you don’t see on any other web page as well. I wish Django would provide some proper way of handling more dynamic pages. Ugh
Superficially, I dare say that there are easier ways to implement what you’re trying to do if you believe that
is your only solution.
The combination of Django with JavaScript is extremely powerful, and I’ve never found what you’ve stated above to be true. The ultimate solution may not be immediately obvious, but I’ve always found one.
I don’t understand what the requirements are for this particular issue you’re trying to address, so there’s no way for me to provide a detailed answer.
The user should be able to sort the data by field (sort=fieldname, order=asc) and filter by two different fields (color=green/blue/…, shape=…) and go through pages (page=). And the user should be able to search data in the table (query=…).
I was trying to work with a form. The form should validate some things like the query having min. 3 chars. But entering 2 chars in the query should not present the user from changing page. (Which is why I accessed the form…value fields and not cleaned-data, that is only available on valid forms).
I found forma also to be less ideal, because I don’t want to wrap the entire page into a form, the query being at the top of the page and the paginatior at the bottom.