5 ms·

Could you give a description of some subsystem that has been architectured in this way, and then provide a concrete example of some methods that implement this

by nsomaru 10y ago

Could you give a description of some subsystem that has been architectured in this way, and then provide a concrete example of some methods that implement this pattern and why it is bad? We are users of Django, and it helps us to deliver projects, quickly. Interested to know how you think things could be improved.

stuaxo 10y ago
Not sure what it's like now, but the insides of the admin used to be fairly terrible (generating HTML with strings for instance). There was a patch to change this to use templates, but it was rejected at the time as it slowed things down too much. FormWizard (which I hear doesn't exist now), was a nightmare to use for any sort of complex form - I tried to do just this and had to call many private methods. I understand metaclasses, but found the implementation of the ORM a little overcomplex. Trying to use the ORM API to work out the structure of the DB was a bit of a pain last time I tried (had to call private APIs).
- samwillis 10y ago
  The core Django developers will (and have) freely admit that the admin interface implementation is a bit of a mess. There is an enormous amount of technical debt in it. It is however not a "core" part of Django and there are many alternatives. I think most people would agree that the correct long term solution to the admin interface is a complete rewrite, however the cost of doing so is too high. The html forms (used in the admin and everywhere else) have until now been generated from strings, however the next realise 1.11 (went to alpha yesterday) this has been changed to using the template tools.
  - throwawayish 10y ago
    While the admin code is kinda messy it's still easy to extend and customize. I'd be somewhat surprised if you could make something that dynamic and not be at least a bit messy. I myself and also other people I know have written quite some domain-specific applications almost entirely within the Django admin, which are as a result: secure, fast and easy to use, which in some cases are not just a bit better than the existing commercial tooling in these domains.
scrollaway 10y ago
I disagree with the parent post; Django's codebase is overall pretty high quality. It definitely used not to be that way, though. But there are components that fit that. The entire form subsystem is awful to work with. Working with Javascript, webpack apps etc is a huge pain. The template syntax is also a failed design experiment, based on the premise that backend coders and template authors are not the same people and should not have the same level of power -- some of this is based on a good idea at its core, but Django ended up backtracking on that half-way and we're now with a very inconsistent template system and having to implement kludgy template tags and filters or new object methods that do not take parameters whenever we want to do anything remotely complex.. At this point I wish it'd just move towards supporting Jinja syntax (that is, alongside the regular syntax, not as a separate engine like it's currently possible).
- acdha 10y ago
  > Working with Javascript, webpack apps etc is a huge pain. Could you explain what you mean? Django doesn't need to have any connection at all to your JavaScript stack.
  - scrollaway 10y ago
    If you want to use the Django staticfiles system (which you do - it's good and useful for non-js stuff as well), it kinda does. We use Django Webpack Loader for our sites: https://github.com/owais/django-webpack-loader https://github.com/owais/django-webpack-loader - This allows us to do `{% render_bundle ... %} which pulls in the appropriate script tag. But even then you can really feel how painful it is to work with, especially if you're adding typescript/scss to the mix. Solutions like Django Compressor are not really the right model anymore. And there's other issues as well. If you want to share settings between Django and the JS stack for example, you'll need to build your own pipeline for that. Building a form in react? Say goodbye to DRY on the form fields. Just, in general, Django predates JS apps being anything more than in-place enhancements and it shows.
    - Daishiman 10y ago

by nsomaru 10y ago

stuaxo 10y ago

Not sure what it's like now, but the insides of the admin used to be fairly terrible (generating HTML with strings for instance). There was a patch to change this to use templates, but it was rejected at the time as it slowed things down too much. FormWizard (which I hear doesn't exist now), was a nightmare to use for any sort of complex form - I tried to do just this and had to call many private methods. I understand metaclasses, but found the implementation of the ORM a little overcomplex. Trying to use the ORM API to work out the structure of the DB was a bit of a pain last time I tried (had to call private APIs).

samwillis 10y ago
The core Django developers will (and have) freely admit that the admin interface implementation is a bit of a mess. There is an enormous amount of technical debt in it. It is however not a "core" part of Django and there are many alternatives. I think most people would agree that the correct long term solution to the admin interface is a complete rewrite, however the cost of doing so is too high. The html forms (used in the admin and everywhere else) have until now been generated from strings, however the next realise 1.11 (went to alpha yesterday) this has been changed to using the template tools.
- throwawayish 10y ago
  While the admin code is kinda messy it's still easy to extend and customize. I'd be somewhat surprised if you could make something that dynamic and not be at least a bit messy. I myself and also other people I know have written quite some domain-specific applications almost entirely within the Django admin, which are as a result: secure, fast and easy to use, which in some cases are not just a bit better than the existing commercial tooling in these domains.

scrollaway 10y ago

I disagree with the parent post; Django's codebase is overall pretty high quality. It definitely used not to be that way, though. But there are components that fit that. The entire form subsystem is awful to work with. Working with Javascript, webpack apps etc is a huge pain. The template syntax is also a failed design experiment, based on the premise that backend coders and template authors are not the same people and should not have the same level of power -- some of this is based on a good idea at its core, but Django ended up backtracking on that half-way and we're now with a very inconsistent template system and having to implement kludgy template tags and filters or new object methods that do not take parameters whenever we want to do anything remotely complex.. At this point I wish it'd just move towards supporting Jinja syntax (that is, alongside the regular syntax, not as a separate engine like it's currently possible).

acdha 10y ago
> Working with Javascript, webpack apps etc is a huge pain. Could you explain what you mean? Django doesn't need to have any connection at all to your JavaScript stack.
- scrollaway 10y ago
  If you want to use the Django staticfiles system (which you do - it's good and useful for non-js stuff as well), it kinda does. We use Django Webpack Loader for our sites: https://github.com/owais/django-webpack-loader https://github.com/owais/django-webpack-loader - This allows us to do `{% render_bundle ... %} which pulls in the appropriate script tag. But even then you can really feel how painful it is to work with, especially if you're adding typescript/scss to the mix. Solutions like Django Compressor are not really the right model anymore. And there's other issues as well. If you want to share settings between Django and the JS stack for example, you'll need to build your own pipeline for that. Building a form in react? Say goodbye to DRY on the form fields. Just, in general, Django predates JS apps being anything more than in-place enhancements and it shows.
  - Daishiman 10y ago