You kind of get used to doing stuff a certain way and it's hard to get out of that mindset. So the issue I had with the recent application was that it had to scale with a basic table and it had to have a lot of entries and scale, well, not a lot, but it still was pretty slow

to add each content and stuff like that. So usually when you start working on an application in Plone, you think about how can I map this to content types, how can I introduce this directly into the Plone machinery and be completely integrated with everything.

But your application doesn't necessarily need that. I mean it's good, you get a lot of stuff for free, you get the workflows, you get the security, you get the automated mails and all of that stuff.

You can set up certain users, but you get too much stuff and usually your application might not need everything, but Plone does everything either way if you use content types

to manage your internals. So that's really, really slow. So this simple example would be, let's say, a table application if you want to present

some information, filter it, fetch it from somewhere. You would have a dexterity container for the table and some items, some contained items, let's call them table rows. You would go add new table row, fill in the fields, and then a custom view for the

table container that would present these rows. Then you would have sorting and filtering from the catalog, which in certain cases can become stale and your entries would not update properly.

So this is how that would look like. Of course you need to add the interfaces and register the DCML files and everything. So in my case, I got really tired waiting for half a second to add every single content

type because my use case, I had a lot of, being a more mature application, I had some event handlers that, sorry, I had too many event handlers and I had the catalog that

had big indexes. So the cataloging step was somewhere around 0.3 to 0.5 seconds for each content being added. So I looked into alternatives and I found that the easiest way to add something into

the ZODB is persistent. I thought it would be simple item, but simple item is not that simple. And the thing is that persistent objects are really, really fast because they're basically

just simple, they're really close to the basic Python object classes. So in my use case, in our example use case, the table would still be a dexterity container because we would use that to interact with Plone and be able to add the application

and set up views and even launch events for other stuff. So now we have an attribute on the table container, which is now an instance of a B-tree with object keys and object values. And the table row is an instance of persistent.

And you can sort and filter the data for display using just sort and filter from Python because once you have such lightweight objects, you can actually iterate through them really, really fast and that won't be a problem.

The catalog would not be needed. So this is an example implementation. Table is a dexterity container. The rows, I added it with underscore rows because I just wanted to make sure nobody can accidentally

access it through the URL and instantiate it when accessing it the first time. And table row is a persistent object. Okay, so this is what I used it in. I had in use case production.

Existing implementation was with actually, that's wrong, with an archetypes item with just a few fields. And the initial requirement was, I don't know, 20 objects in a container. And eventually that grew to something like hundreds of items and they had to be managed

in bulk. And we wrote a custom view to import data and it was very slow because this was also a big portal and it took about one second to add or update one item.

And average data set was something about 300 items. And it's really frustrating to manage data in this way if you have to go away for 10 minutes. And we even thought about using asynchronous jobs and that's where red flags started and

red lights started. So we thought about it and I implemented it with persistent objects. I set the fields as attributes just like before in the example in B3s and now it took

less than a second to update 10,000 items. Not that we needed them but we go from, I mean not yet, but we went from 10 minutes to less than a second. So that's a really big improvement. We did not have to implement async.

We cut a lot of the existing code actually. And now several resources can be better used to do other stuff than wait around for 10 minutes. Another advantage to this approach is that non-PLON people can work on your application

because they can just write normal Python objects. Just ask them to please use persistent or you just port it over after the fact. And so you can expand your developer resources without having to teach them PLON.

And it's really easier to test. You don't have to spin up a PLON instance with the database and all the packages. You can just test your implementation separately.

But of course the drawbacks are you don't have any permission checks. If you have a collection and you need user-based access or role-based access, you have to check them in your custom views and make sure you don't return any data they shouldn't access.

You can't add, edit or delete them through the web because they would no longer appear in the menu. But you can of course create management forms that are not that hard to make. And you can even skip using z3c form because that wastes a lot of time for me at least.

So it's not a content type. You lose everything that was content type related but you can get most of that stuff back. Not all applications need to follow this pattern.

If you have a news item or stuff that you update rarely or not a lot of them, you can just follow the standard pattern because you get a lot of stuff for free. But if you need performance, if you have applications dealing with a lot of data, this would be extremely fast and easier to test and a lot more people could work to develop it.

If I have a little bit more time. Okay, I've set up a quick test implementation of how this would work.

I don't know if you can see this.

Is it visible? Okay, so I have this.

I created a dexterity content type in Plon through the web interface. And here I have a browser view with two functions. One that adds dexterity items and one that adds persistent items. And one that returns the persistent item.

It returns 10 random persistent items because we're adding 10,000. And this is the persistent item. It's really simple. Whatever you pass in as keywords, it gets saved on itself. And I've set these here just for reference.

Okay, I have a names list. Which contains some data and I will be adding 10 dexterity items.

This is another package that logs everything that's going on. So added 10 items in 2.5597 seconds. That's not that bad, but this is a plain Plon site with nothing extra in it.

No extra indexes, no extra anything. So let's see how fast it would be to add 10,000 items. 0.1 seconds. And this is the table. Just use some named data from a website.

And we get random data. So yeah, this is what you can get. You can get much faster performance and simpler code if you're willing to lose some functionality that you might not need either way.

So thank you. Questions?

Have you looked at the super package, like the soup ER package? It has a similar approach.

And yeah, we use that for the shop, for example, for all the order data and stuff like that. No, I did not know about this package. It's quite a similar approach. Okay, so we'll have to talk about this. There's a Plon integration package as well. Okay, thanks.

Hi, just to understand, I mean, I didn't get it fully. So you have a dexterity content type and then you take part of it and put into persistent persistent?

The idea was to go away from the dexterity content type. So in that case, I had a table which was a table container. That contained table rows. Table row was a dexterity item. So I would end up having, let's say I needed a thousand of those.

And I have to update them. Yes, but I just didn't understand what you described. I mean, did you combine? Yes, so now the table, the container contains an attribute, a B-tree attribute, which contains these persistent objects.

Yes, so this way you can have all the security based on dexterity, if I understand correctly. You can, but you have to be careful if you have a view that says list data and it should be according to whatever permission the user has. Maybe some people see something else. Then you have to filter what you send them.

Because if you say just list everything, then... Yeah, that could be wrong. Okay, but it's an interesting approach at least. Thank you.

So if you look at the method resolution order of a content type item from Planup content type, for example, there's 44 classes in there.

And well, as expected, one is persistent-persistent. And why, if you say you want to add new functionality, like workflow, for example, or security, why do you not build your own content type by picking whatever,

since it's built so modular by picking what you think is your best, the lowest entry point for the minimum requirements that you have. I mean, simple item is not that complicated, I'd say. But if you add more and more, going up the method resolution order,

it gets more complicated and more heavy, especially if you go to CMF catalog-aware and workflow-aware. How many things did you actually add, and which of them did you add by hand?

And why not use one of the modular elements that Zope and Plon provide? I did not want to look through that, that whole thing. And what I added was a management page where I would add and delete and edit items, which is not that complicated.

And yeah, no, I did not need workflows, I did not need anything else, because everything would be implemented through the parent container, in my case. And you can even send custom events for the content rules,

if you want to send emails. Thank you.