And now I will hand give the floor to Emma, who will give her talk on Jango Atman.
Thank you.
So hi, my name is Emma.
I've been doing Titan for a long time.
Recently, I do more Jango.
I am a member of the PSF, the DSF.
And I'm currently a member of the Jango steering console.
But this is not a steering console talk.
This is my talk.
I also worked for a small company that I confronted.
Left it.
We're in Belgium.
We do mostly heavy data based web application using Jango.
And for bigger projects, I also work with Squats, who gave me these t-shirts.
Squats is the teams of teams where you can basically hire a team and just play what you need.
Since this is a Python demo, I'm first going to introduce Jango.
Who doesn't know what Jango is?
So I have three people into the form of president who doesn't know.
Jango is the web framework for perfectionist's deadline.
It is the most popular, so far, I think it's still the most popular.
Web framework in Python, it's been around for 20 years.
It's very mature, stable, and it's got a good community.
And it also comes as batteries into the things like authentication.
You where I am, everything like that.
It's also used across open source projects.
I think it's like authentic, paperless, but also big names like nasus,
GPL, and so forth.
And one of the most light batteries of Jango is the admin.
And so for the two people in the room, we don't know what Jango was.
This is what the admin looked like.
The admin lets you create a crowd really quickly on any table in your database.
Jango supports many database backends.
And so if nothing else, you can use that to reverse your database if you don't have a correct client.
And it's better than most clients, because it's also this relationship and things like that.
Oops.
And to write such an admin, it's quite easy.
A few lines of code, and you know have something that lets you explore your data.
Dupe thread, 80% of what you will probably want to do with one single table.
You can do that in a few lines of code.
What's not so great is that Jango is 20 years old.
The concept of the admin is also 20 years old.
And so there are things that for not built into the admin.
If you want to do a drag-and-fout, if you want to have nested in lines,
if you want to have extra actions, not just edit and delete with your staff.
There are third party packages for all those.
But the problem is that when you start to get too many third party packages in your Jango application,
you start sometimes to get conflicts.
And there are really more complicated stuff.
So if you want to change the layout of your form,
well, most of the time, the best way to do that is just to do it by hand.
The thing is with the admin, is that a lot of the admin code is in two places.
It's a changeless view and the change form of you.
And those two things are buried deep inside the admin.
And it doesn't really look like anything else in Jango.
If you want to take a step back, the Jango admin is a framework inside of Jango.
It's its own thing.
If you know how to do filters in the admin, and you want to do filters in your regular views,
well, it's completely different.
You, your best bet is to install the third party package,
because it's not there.
Jango is filtering, but only in the admin.
And the community knows that there are a few issues with the admin.
Last year, the steering console introduced the new features people,
which is a place where we can ask for feature,
idea, it's a repo and GitHub, it's organized in a convenient way to follow where the things are along.
And about 30% of the issues that were open there are about the admin.
And there is one issue, specifically, issue number 70 that was open,
that kind of got my eye and sent me down its rabbit hole,
and because of issue 70, this is the reason why I'm standing here today.
I will come back to the rabbit hole later.
And not only the community knows, but the community has been trained for at least 15 years.
There's Django admin too, which is factory revs, Django standard views.
The problem with Django admin too is that it's still very close
in a concept to the regular admin, and it's also been abandoned,
and Django 2.2 is the last version in supports.
Next to that, you have things like Drap Ali in Jet,
that are mostly skins over on top of the admin,
but it's extra functionalities.
And then you have people who do things completely differently.
You have Wactel that is CMS, one of the most successful CMSs is built on Django.
But it has its own admin, and some people have taken that admin,
removed everything that was CMSC from the admin,
and used that instead of Django admin.
And then there are people who just go outside of spite and altogether
to use Django with rest framework, and they built a JavaScript front end.
I wrote a library to do that, and this is one of the forms
that I'm able to manage with that.
And I would love for the admin to be able to do that out of the box.
And it's not just a community, also a side of the community.
Other frameworks have been evolving.
20 years ago, while there was frails, there was Django,
and there was not much else in terms of having an admin.
And even Django, in Django, seeing, hey, we're doing this because frails does that.
But in the past five years or so, things have started changing,
and the other frameworks have mostly caught up,
but they're also starting producing new stuff.
They're starting to introduce dynamic companies there.
They're evolving, while Django is still evolving,
but the others are there, you know,
and they've put up in some areas they have gone further.
So what does this mean for the future?
I would love the future to be extendable, composable,
and I would love the future of the Django admin to be just Django.
What if when you write something for Django,
you can also use it in the admin directly and vice versa,
instead of having to deal with two different paradigms,
that the admin framework inside Django and Django.
So I kind of went into a rabbit hole, like I said,
and I looked more at what would that mean?
Well, it would mean that it would have to be built on Django's generic views.
Thread operations, of course, should be supported,
but they should not be anything special,
and it should not be more special than publish or clone.
And also everything should be composable,
so you should be able to take different parts of the framework
and put them together.
And for that, plugins need to be key,
and I like the Django admin that was first created
inside a newsroom in the US for very specific purpose,
try to think about the plugin as first citizens.
And of course, it should be very familiar.
So you put it in images.
If we take the structure, that would be the Django views at the bottom.
On top of that, you add some niceties, some UX,
some websites, side bars, that kind of thing.
And of course, there's not just visual things.
You also have to handle things that throw behind the scenes,
I permission and all that.
And a way to put that together would be plugin,
using something that is already well known
and supported for the Django plugin is one of those.
And the glue that would come and bring all of that together
would be few factories.
So you register a third-party application,
using the plugin interface,
and then when you're looking at the list view,
Django knows that for your list view you're using this,
that and that plugin.
And it brings out everything together.
And of course, I said earlier, this should all be familiar.
So back to Django admin definition.
This is what an admin definition looks like.
And when I went into that private hole,
I wrote a whole proof of concept, right?
And so this is Django admin do.
And this is what this looks like in Django admin do.
Did you spot the difference?
The only difference is the imports.
So this would stay very familiar.
It would not break anything that you know about yet.
But once you have changed those imports, you can go further.
And you can enhance your admin with things that have been included,
that are not possible right now with Django core admin.
So for example, instead of using just strings,
you can use colon objects and give more information about your colon,
like change the label or things like that,
which is say it's sortable or filterable.
Or you can, for your form, you can also use a layout object,
just using a list of fields or fields like this right now.
But that's nice and theory.
But would that really work?
Yes, it would really work if I can get my mouse to put that into full screen.
This is a demo of Django admin do.
And when you look at it, you might not see anything.
You might think this is just a Django admin.
And this is good.
This is what we want.
We want it to be funnier to look at something that you know.
And here this is just Django admin.co.
We don't any of the plugins.
And yeah, you see that it works.
And it's not in special.
But here you can see that there is a difference.
There is this change password action.
Right now in the, in the current Django admin,
when you have users, you want to change password.
You have to edit the user, then you have a link to the change password form.
Here you could have that directly as an action.
Because once again, other actions is not just edit and delete.
Other actions list have the same status.
You can find them on any thing here at the bottom right.
You have to delete and you have to edit.
And you have changed password that are accessible.
So here I'm going to delete the user.
And so one of the things that I was telling you about something
that for some reason, very important to me is to be able to have different columns
easily next to each other when you're doing a form.
So this is the case here.
It's just a simple Django form, but you get more flexibility.
That's what you do get out of the box with just no plugins.
But now we're switching to dark mode.
Dark mode is Django admin.
With the recommended plugins.
That's Django filter that Django from set.
So here we can see that you've got all the things that you're used to having in Django admin.
On the right, you've got filters, you can search your views, you can search your list.
The plugin, so the search on the top right, is provided by the core.
But the filters is provided by the filter plugin.
And those two, they work together without any issue.
The form here is rendered by Django from set.
Django from set.
If you don't know, it's a library for doing forms in Django.
Django is very powerful.
You can do things like conditional display in that kind of thing.
And other than it's dark, you probably wouldn't have seen the difference if I had
Untiled you, it was rendered by another library.
And this is the idea.
It should be transparent.
It should stay familiar.
It should not bring anything different.
So here I'm going to be trying the filters.
This is very powerful.
And yesterday again somebody was saying, yeah, but the problem when you start to use plugins and plugin
is that you don't always know what's happening.
You don't know what plugin introduces what into your view.
You have a hard time allocating the code and so on.
And so with great productivity.
And because of that, Django had me do it comes with another plugin that documents.
Every view that has been created that has been assembled from your base view and all the plugins
that come over that, it creates a full documentation website with everything.
And it looks a little bit like CCBV, except that it's focused on the plugin system.
It tells you, yes, this is the base view.
This is a base view class.
If this plugin that plugin and this is where each function code, which matters come from,
each property comes from and how they ended up there.
This is a plugin that generates a website, but there's also a common live version that can give you
a few smaller details about that.
In last year, somebody in this room asked,
why did we still need to rest third-party application to do rest in Django?
And so I wrote an article saying that you did not.
And then I wrote a library that did it, so it defeated the purpose.
But I thought, should I try to break this?
And so I wrote a plugin.
I made a plugin version of that library that can stick into Django admin.
And so you can, why am I speaking so fast compared to my slides?
I made a plugin that's just asked rest to anything from Django admin.
So now you have rest.
Let's just like in the other action.
Getting, doing a get, doing a get-feed quest with JSON.
You're getting exactly what you would get with any other rest framework.
And just to test it, I also, because I think it's still cool to do to do applications,
when you want to do JavaScript and rest.
So I did a small-to-do list application that uses that trust framework from Django admin.
And I reload it several times just to show you that it saved some disk in the database,
not just JavaScript metric.
Yeah, that's it for that.
So this is the list of the plugins that you saw at work.
And this shows, this is to show that plugins have been designed into this proof of concept,
as being first-class citizen, even the core.
It's Django admin, the plugins core.
Everything is plugins.
The other thing is that you can try this without any risk,
because it's another application altogether.
So it can live right next to your admin.
And if you want to try it, and if you want to migrate,
you don't have to switch from the stack admin to Django admin.
You can just do one model at a time and start your migration.
Of course, the admin itself is nice, but there is a whole lot of other things around the admin.
There is a full ecosystem of applications.
And some of the third-party application will be easy to migrate.
Some will be less easy, and some will be hard.
The easy ones are the ones that either not necessary anymore,
or don't do anything visually or that kind of thing.
And the more visual things that a third-party application is going to be doing,
the hardest is going to be to migrate it right now,
because it's a whole different system.
And under the hood, even if the API, the final user's API is the same.
Under the hood, we got a threat of the changes view.
Of the changes view, of the change from view,
those concepts that are only part of the current admin,
we got a threat of those.
So, teams, for example, I would not advise anybody to do a team right now,
except maybe some CSS customization, because the templates are changing a lot.
Four things like Django Reversion that adds a sidebar in the admin.
Well, we have a plugin that the sidebar thinks,
but this will have to be translated to be compatible,
which is sort of the plugin.
It's going to take a bit of work.
So, if there is enough success in people like the idea,
this is roughly the roadmap, that's a project like that we need.
It decor itself with still needs several months.
Mostly clean up.
I did the architecture.
I delegated a lot of the codes to a robot,
so no, I really have to do a lot of clean up.
Taking care of the third or key positioning is important.
But most importantly, if this goes forward,
we will have to accompany the whole community,
help people do the transfer, and not just say,
hey, this is a new admin.
No, you're on your own.
So, this is going to be what's taking the most time.
Unfortunately, time is money.
And this is probably why, up until now,
there is not been any change of doing something like this.
Jacob Caton must say that it would take about a million-dollar
to rewrite the admin.
And that was 10 years ago before inflation.
So, the DSF does not have money for that.
The DSF barely raised 300K this year.
And the DSF uses its money to maintain Django,
not to add new features.
The only feature that I'm aware of in Django
that kind of got some funding with the migrations.
And that was about 10 years ago as well.
And this was brought from it.
It was not funded by the DSF.
But now, we have things like the severing textants
and where people try to, of the Europe,
if willing to invest money in open source.
So, I'm thinking of maybe reaching to that.
There's also other systems.
Django is framework.
There's proof that you can help other companies
integrate the product into their own product
and that they're happy to pay for this.
Consulting time to do that.
So, what could come next?
We have, I said, we have some clean up to do this.
More permission plugins to do more granular permission
that was currently implemented.
What we have is already more, has more choices already
than the current admin.
But we want to object a little permission
to build permission, that kind of thing.
We want to improve with a model,
related model, functionality,
internationalization, and much more.
And if you're interested, if you want to try this,
maybe your feature, maybe your feature you need.
If you want to, go contact me after the talk.
Because in order to move any further,
this project needs you.
It needs people to try the project.
It needs people to give some feedback.
It needs people to find bugs
and find possible improvements.
The best way is to give feedback is to either go directly
on the project's repo or go on that issue
70 on the new ideas repo.
So, it looks like I finished in time
and we have time for questions.
Hello.
Thank you for the talk.
Thank you.
I have a question that might be controversial,
but you talked about core.
Yes.
Is there any chance that some of these core
could be reused for a fast API,
so that we could help and contribute for both communities?
I said controversial.
No.
It's just, I don't know.
I think maybe.
So, this core, we believe that there
would need to be a similar core for fast API
and then have plugins that work for both.
That might be a solution,
but then how do you deal with the ORM and things like that?
Yeah.
So, fast API doesn't come with its ORM,
but you could use, like, a small community or something.
Yeah.
Or you could actually use a Django ORM with fast API.
Yes.
It would work.
And then it might work.
It might.
Thank you.
You're welcome.
I want more questions.
Hey, Emma.
I've put the API part of the project is really cool.
To what extent do you think it would be useful
in, sort of, large scale production code with,
mainly API features, for example,
is it your vision that someday it could replace
the need for Ninja ORM framework?
Or is it just something basic
that's kind of a helper utility?
How do you see that feature?
So, it would definitely not replace
Django ORM framework,
but it could come on top of
Django ORM framework.
Right now,
Django, why do I say Django in the day?
Ninja is a lot of manual work to create stuff.
So, there is, among the long list of things to look
at, a Ninja plugin,
that would help,
and maybe manually,
automatically create the serializers
that kind of think.
And that would definitely be something
that's this kind of plugin system
or the load to do.
Same thing with Django or framework.
Django or framework is much easier to do
because there's already an application
that does that, is the RSKM adapter.
And it automates a lot of things.
So, that's something that I could do much faster.
But yeah, the rest application is,
mostly, I'm not going to say the size.
The small resting is something
that you would use if you just have one or two
rest views.
And you don't need an old thing.
If your whole application is based on an API,
well, you should probably use a third party package
that is specializes in APIs.
But this could really come on top of that
and help create factories for the views
that you need to use a Ninja behind the scenes.
Yeah, thank you.
I think it's really cool.
Really exciting idea.
Thanks. Thank you.
Do we have questions from the chat room?
Do you know?
No questions from the chat room.
Okay.
If that were all questions.
One of the hands last question.
And then we go.
Really cool concept.
If there was the funding to get this third and third
of would this be something that could replace
Django admin, would this be a final goal for a project?
So, yeah, so if there is funding,
so I'm one of the things I'm going to
walk into is getting funding
either from the surroundings or
I was not kidding.
If any of you has a company that is interested in the project
and wants help to integrate it, call me.
So I'm hoping to get funding
and if there is funding and if there is enough.
There is other people in the steering council who think
the idea is interesting.
So there could be something that lands in Django
to replace the Django admin.
If that happens and nothing is going to happen.
But if that happens, we will need to set a new
deprecation policy in place to
deprecate the current admin in maybe two or three version
to major version instead of the current one major version.
And probably what would land in core would probably be the core of
Django admin do and leave the plugins outside.
Right now, this is not going to happen.
I hope it's going to happen later, but I don't know.