Update version about django-convenient-formsets

[tiesjan]

Thanks for both your input. I've added a fix and clarified the expected structure in the documentation in 34319d8. Let me know if you still find some bugs! 🙂

---

The first problem is that it returns an element, the form would need to have a parent element, I believe this is optional, or not?

@CleitonDeLima It is correct that the form would need to have a parent element, but in practice this is already the case due to the formSelector parameter. Nothing changes here, it's just clarified in the documentation.

As for storing a stringified empty form in an attribute on the add form button: I consider this out of scope for this library. For simplicity, I would rather focus on handling DOM elements only. Also, rendering HTML code inside element attributes may not be the most secure approach.

---

One more thing: I noticed there is a mismatch between the README version displayed on the GitHub and PyPI.

@joahim Correct. The README file is read inside setup.py, so PyPI will automatically be updated in the next release.

[tiesjan]

Version 2.0 has been released! 🎉

[tiesjan]

Hi @CleitonDeLima, I plan to do a release shortly after Django 4.2 is released in April. It will include several new features and deprecations.

[CleitonDeLima]

Nice!

I also saw that the empty form was changed using the template tag, perhaps due to an error when deleting a form. I haven't been able to test it yet, I just saw the code.

[joahim]

A quick comment regarding the use of the <template> tag. The <template> behaves differently to the normal DOM elements (see https://stackoverflow.com/questions/66137470/template-queryselector-inside-template-tag-not-working for details). The example on the django-convenient-formsets is using IDs for all the elements and so the example works but if you rely on classes, then using the <template> will raise Unable to find DOM elements with selectors.

[CleitonDeLima]

he example on the django-convenient-formsets is using IDs for all the elements and so the example works but if you rely on classes, then using the <template> will raise Unable to find DOM elements with selectors.

Agree, the use of template is good. But what might not work is the removeChild method. Template clone results in a document-fragment and not a Node. This should be easy to fix.

https://stackoverflow.com/questions/28827977/webcomponents-remove-cloned-template

[tiesjan]

I see, thanks for pointing this out. I wasn't aware the removeChild method wouldn't work here and apparently this is not covered by the end-to-end tests either. I am able to reproduce that exception now.

It seems that one way to fix this is by cloning template.content.firstElementChild instead of template.content directly. This would require the <template> tag to contain a single element only, which in turn contains the empty form. This is the exact structure as in the example and how I usually use the library, so it sounds like a simple but good solution to me. Any ideas on this?

@joahim I don't quite get what difference it makes in using classes or ids and whether this is related. If I understand correctly, the library needs to find the <template> tag using any query selector and from then on simply clone its contents. Am I missing something?

[CleitonDeLima]

Any ideas on this?

The first problem is that it returns an element, the form would need to have a parent element, I believe this is optional, or not?

[CleitonDeLima]

The approach I use on my system is for empty_form to be a string and it is added to the add form button.

Why this:

• I work with nested formsets, I need to identify each formset container from the lowest level of the dom to the container
• it is better to replace the __prefix__.

This is just one of how I solved my problem, but here's the record.

[joahim]

@tiesjan please disregard my ramblings about using ids vs classes :-) I confused two different problems when trying out the <template> approach.

As for the solution: I personally like the idea of using the <template> tag and therefore like what you propose. And it would be good to make this choice clear in the docs if you decide to use it.

One more thing: I noticed there is a mismatch between the README version displayed on the GitHub and PyPI.