rcrowther / django-streamfield-w

A StreamField for Django. Ported from Wagtail, with new DjangoAdmin-like API.
BSD 3-Clause "New" or "Revised" License
27 stars 4 forks source link

Implementing outside django-admin #3

Open nikolas-dev opened 2 years ago

nikolas-dev commented 2 years ago

In django admin works great. Is there any planning to implement using outside django-admin?

rcrowther commented 2 years ago

First, my apologies for a slow reply. I was on holiday.

This is a question about a feature that would be obvious. The question deserves an extended answer. Django has base code for form-building i.e https://docs.djangoproject.com/en/4.0/topics/forms/. But unlike other systems it has no "form-builder" e.g. a fully-abstracted .form-description meta-language. Django also has no system of convention either,(maybe you would argue otherwise?) like I used to use ,for example, in Drupal 6. This means Django can be versatile when creating forms. But makes it more difficult to provide code that will work for everyone.

When I built this module I had my own issue. Wagtail's Streamfield implements a new approach to an old problem. I think the approach is wonderful, the answer everyone wants and needs. But the code is difficult---I think I've made that clear in the README. The Javascript is extensive, and tangled. The trigger code is difficult (and not well-documented). This is not a comment on Wagtail's standard of coding, only a note that a radical new idea has a tricky implementation. Which gives me a maintenance problem. Will Wagtail change their implementation in the future (I've not looked at all, given my situation during the virus curfews)? I found ways to extract the code that didn't interfere with the way Wagtail writes to storage.. This is what I care about---that people will not need to rebuild data, but that data will always be accessible.

But adding extra features troubles me. I was happy to add the ability to make list items as it will generate Wagtail-standard data, But extra code and/or API for forms would be an extension. If I had commercial backing, a guarantee that someone needed updates to work, so would back the module with code-time and personnel, then I'd consider the feature. Even regard adding out-of-admin-forms as as an essential feature. But my current position is that Wagtail's implementation may change in radical ways. At some time in the future, I may need to make a radical rebuild of this module. Fortunately I can rely on Django's policy of conservatism and stability, which means the module should work well for years (which it has done). But without a guarantee of resources for development, I won't add code that extends the module. This suggestion is a natural extension of the module, which I am sure many would welcome. However, it may create a maintenance issue, potentially a very big maintenance issue. Sadly, an issue I don't have the resources to cover.