The great thing about the Django Admin is that - because it was actually part of the Django itself - there is a whole ecosystem of extensions, add-ons, skins etc for it.
Any attempts to replace it for Django would have an uphill struggle for that reason alone.
This is one side-effect of an opinionated framework - the provision of a default choice facilitates cooperation and prevents fragmentation.
(We recently picked up a Pyramid project and I was rather surprised how big the impact was of the extra choice. Simply in terms of searching for answers to questions - we often had to find an answer from someone who was using the same combination of parts that we were using. And figuring out how to do x often fell into the gaps in the docs between two components and was therefore harder to figure out)
Possibly you also ran into the Q/A problem because there are many more people who use Django and common issues/gotchas that people encounter have mostly been explored and documented. I haven't used Pyramid but I would imagine the user base is somewhat smaller.
I've used Django Admin, and it is definitely really cool. However, I don't think it comes close to being a requirement for web development.
The awesome thing about Flask is you really only need to use what you need to use.
Flask also has really great support/docs/etc. I haven't had to google much to find answers to even the more obscure (use xyz supporting library) questions.
Not to be a Flask fanboy... Django definitely has its place. Flask works well for me.
The thing is with Pyramid IMO that you have to have some experience with Python (and its ecosystem) to be able to use it effectively. It's clealry much more flexible than either Django or Flask and has more advanced concepts and features (such as view predicates, declarative permission system, URL traverse, etc...) but you have to be able to use it.
> Yes, default Bootstrap skin looks boring and unprofessional,
Sigh... bootstrap didn't get where it is by looking unprofessional.
I also don't understand wanting every admin interface one comes across to be a special snowflake, the opposite of what should be the case. We've known for at least 30 years (Apple HIG) that a standardized look and feel is a benefit to users, not a detriment. Not to mention dev maintainability.
I suppose billable hours decrease when reinventing the wheel is no longer necessary.
Uh, that's typical rhetoric about default Bootstrap interface. Like if someone used default bootstrap skin then he's just lazy and didn't really care. Thus unprofessional.
Personally, I think that Bootstrap interface is good enough, but its widespread adoption lead to the perception I mentioned above.
I understand, and that's why I'm a bit annoyed, it's a very developer-centric attitude propagated by the sentence above.
Personally, an end-user has never asked me to make their software/web-admin look unique. A portfolio site? Sure, but an admin page? Not other than their official color/logo in the header.
Uniqueness is just not a concern with "normal" people, and with good reason as I mentioned above. Still, congrats on the nice work on the site/post.
The fact that Bootstrap is widespread, and therefore perceived by some unprofessional, does not make a user using it unprofessional, nor does it make the framework unprofessional.
Are Django or Flask unprofessional since they are widespread?
Unfortunately, you can't compare development frameworks to UI frameworks. No one knows that you're a dog on the Internet. But anyone without technical knowledge can see a site that's built with the default Bootstrap skin and say - hey, I saw it before.
Bootstrap is good and clean framework, it is _great_ for developers. But just because it is so widespread and highly visible, there's some of prejudice around it.
Nonetheless, I'm using Bootstrap in my projects and happy with it.
I think this prejudice only exists within this community where if you aren't that special snowflake you're not cool. I'd guess 99% of web traffic has no clue what Bootstrap is, what it looks like by default, how it is different when it is skinned. I would guess more than anything that they just think, this is what a website looks like now-a-days.
I'm happy to use it too with very minimal tweaking because it looks good out of the box, way more pleasant than browser defaults, it works well, fairly well maintained.
While that is true I think that most users will be oblivious to the commonalities - as developers we are not only familiar with bootstrap but also with the myriad developer-built sites that are more likely to use it
Flask-Admin is a batteries-included, simple-to-use Flask extension that lets you add admin interfaces to Flask applications. It is inspired by the django-admin package, but implemented in such a way that the developer has total control of the look, feel and functionality of the resulting application.
I especially like, that I can use Flask-Admin with Peewee ORM - https://peewee.readthedocs.org/en/latest/ - instead of SQLAlchemy, because I feel so much more comfortable with Peewee when doing small CRUD projects. SQLAlchemy is a lot more powerful, but the learning curve (at least for me) is steeper than with Peewee. Flask-Admin is a beautiful piece of software to get Flask backends set up quickly.
I haven't used it myself, but I took a good look at the code for PeeWee for some changes I wanted to make to Django. It's incredibly well written, and weighs in at about 4000 LoC including 3 database specific dialects (pg, mysql, sqlite).
Getting the admin-interface correct is one of those holy grails. The problem I typically run into is adding complex wizards or features outside of the standard crud stack.
When I'm investigating an out of the box admin interface I'm _less concerned_ about how they handle CRUD; that's the easy part. Really I need to know how they handle things that go well beyond their stack.
For example, in one application we need to create events for people (like google calendar). You need to be able to search for people, show the system what they already have assigned at that time and allow you to choose times that are best for everyone in the list. This has been designed as a multi-step wizard and it works great but it was a ton of custom code. Looking at the online documentation of flask I'm not sure how I would go about integrating something like this.
There is a large number of fairly clean well-documented extension points in the Django admin. You can override forms, templates, widgets, entire pages, querysets, search logic etc etc.
In the same way that the answer to questions about Django are often answered by "You're over-thinking it. It's just Python" - many questions about the Django admin can be answered by "You're over-thinking it. It's just Django"
I have the feeling that flask has been neglected for a while. The last release 0.10.1 was on Jun 14, 2013. The mastermind behind Flask, Armin Ronacher, is more into Rust nowadays.
I once started a big codebase on Flask and had to move away from it because of some really strange bugs and bad interplay of officially approved packages. The idea behind Flask is nice and there are great plugins out there like Flask-Admin but I don't trust that code base anymore. Also I found a weird bug that kept Flask from answering more than about 500 requests per second and nothing happened since then. For me it was the right decision to jump to Go.
Agree. Its been 2 years since the last flask release, 1 year since last jinja2 release, as an exception werkzeug had a release 3 months back. But, if we look at pull requests and commits, there has been continuous development in all the repos with new maintainers - https://github.com/pocoo/metaflask
Unlike fullstack frameworks, Flask being a minimalistic framework, needs very little changes to the core, as long as the extensions fill in the gaps.
But still the new commits to the core need to be packaged and released as stable features/fixes. Hope Armin and new maintainers understand importance of releases.
Nice. Definitely something that I miss when using Express for a UI-centric project. Seemed like only the "kitchen sink" frameworks (Rails, Django) had decent CRUD/admin UI options.
Any comment on the comparison with Flask-AppBuilder https://github.com/dpgaspar/Flask-AppBuilder ? I've already made projects with the last one and I think is very nice. Are there any deep diferences, advantages or something I should take into account? e.g. github contributors ;)
Flask-AppBuilder is opinionated fork of the Flask-Admin. It follows similar conventions and uses some of the Flask-Admin code, but comes up with non-default skin and a little more batteries (like user management interface out of the box). If compared directly, existing Flask-Admin components are much more featureful that their counterparts in the Flask-AppBuilder.
Flask-AppBuilder API is not compatible with vanilla Flask-Admin APIs, so you won't be able to exchange components between them. And sure, you can build something similar to Flask-AppBuilder on top of Flask-Admin without changing its core. Or maybe someone already built it (like Flask app skeleton with built-in administrative interface).
I explained reasoning behind default Bootstrap skin and lack of built-in user management in the blog post.
I have nothing against forks, it is good to have multiple options to choose from.
> Campus Bubble is a single page app with React.js on a frontend and Python services on a backend. We use Flask, SQLAlchemy, Tornado (SockJS push notifications), PostgreSQL, Redis - a pretty standard Flask stack.
Can anyone explain how Flask and Tornado could be used together?
They're being used side by side and running in separate processes.
For Campus Bubble, tornado app is a relatively simple push broker. Whenever something happens, Flask app pushes notification to a broker and broker pushes them in fan-out fashion to subscribers.
fask-admin (or any decent CRUD interface) is one of my favourite parts of developing a new application backend. The amount of functionality you can achieve without touching HTML/JS is amazing.
Goes a long way in keeping the application modular and maintainable.
Maybe lead with that it is a CRUD package for the Python framework Flask rather than expecting readers to be familiar with the Python ecosystem enough to be aware of what it is?
I'm still more in favor of Django. There is more to learn about it, but almost all Flask projects that get beyond the weekend-project stage end up reimplementing stuff that is in Django, or working around that lack.
The interplay between ORM, migrations, admin, CRUD, API, Forms, etc is just beautiful. Doing that with SQLAlchemy and the like is possible, but may create a bigger mess than starting out with a slightly less lightweight Django. project.
When using Flask, I like the fact that for form handling with an ORM, there's a flask-wtforms plugin, a wtforms-sqlalchemy plugin, and a flask-sqlalchemy plugin. This is part of the reason why I'm sticking with Django.
This looks interesting! I just started playing around with this a bit, and maybe I'm missing something, but it looks like the ModelViews only implement create, update, and delete? Why no read?
I'd have thought that viewing the details of a model instance (attributes and some relationships) would be very generic use case? But I probably just don't understand how to do this easily with flask-admin as it is. Is there a good place in the documentation/examples to start looking?
I think the generic idea is to merge 'update/view' into the same thing so that you "view" by looking at the "update" form without updating anything. I've seen this in several places, though I'm not partial to the idea. I like having a separation between 'I am making changes' and 'I am viewing' just so that you don't end up with accidental updates.
Right yeah, that explains things. I don't mind this when it's just for myself, but actual users definitely get scared when they see the editable fields and the submit buttons...
Any attempts to replace it for Django would have an uphill struggle for that reason alone.
This is one side-effect of an opinionated framework - the provision of a default choice facilitates cooperation and prevents fragmentation.
(We recently picked up a Pyramid project and I was rather surprised how big the impact was of the extra choice. Simply in terms of searching for answers to questions - we often had to find an answer from someone who was using the same combination of parts that we were using. And figuring out how to do x often fell into the gaps in the docs between two components and was therefore harder to figure out)