Create a real content class in Dexterity pattern

[tomgross]

Currently the Dexterity pattern creates a content with plone.dexterity.content.Item content class (see https://github.com/plone/bobtemplates.plone/blob/master/bobtemplates/plone_addon/src/%2Bpackage.namespace%2B/%2Bpackage.name%2B/profiles/default/types/%2Bpackage.dexterity_type_name%2B.xml.bob#L23) In 100% of my use cases I change this to a custom class living in the package itself. This could be part of the template.

[tisto]

Could you elaborate why you use/need a custom class? Personally I rarely use/need them.

[tomgross]

It lets me a) specify an interface on the type to bind views, adapters, etc on it -> this I need all the time b) add helper methods to manipulate the content.

[tisto]

ok, you need a) only if you use an XML-schema, so this comes down to the decision if we consider a Python or XML schema best practice. This is not an easy decision. We could add an option. Though, we have to be careful, we just removed most questions to keep things simple.

Regarding b) I would doubt that this is the most common use case (we can and should just support the single most common use case in my opinion, otherwise we will end up with an unmaintainable and untestable mess in bobtemplates.plone).

[gforcada]

Being best practice or not, p.a.contenttypes is using b) see https://github.com/plone/plone.app.contenttypes/blob/master/plone/app/contenttypes/content.py

[tisto]

@gforcada plone.app.contenttypes is a good example why custom content classes are usually a bad idea. Those classes are just dead code without any functionality. The only exception is the Collection class and the only reason I added this base class was to support bbb. That should be fixed in the future. Are you volunteering for cleanup tasks? ;)

[tomgross]

Obviously this is a matter of taste. I prefer reading and writing XML for schemas since this is used outside the Zope/Plone world (ie Solr) If we go for interface we should stay with this solution and remove consequently supermodel/XML completely as a core feature. We need then provide the round robin TTW editing <-> product code via interfaces. Doing things TTW was once the cool thing in Zope and was unfortunately forgotten in Plone over the years. Please keep these we have as first class citizens in Plone since it makes it so much approachable to non developers.

[davilima6]

I don't think a class should come by default, at least not enabled. Basic types may not event require any additional fields in the type interface (or xml, if that's the option). For instance, their fields may come solely from behaviors, and/or inheritance. So I'd suggest:

• 1st step: ship a content class but leave it commented, which is an easy PR away and not a problem since it's a skeleton package and integrators should expect to delete or uncomment things if that makes things quicker to customize;
• 2nd step: add it as a local command, following #130, which is a more elegant but slower solution.

@tomgross, regarding a) even if you prefer the XML route, you need an interface on which you'll add the model.load call to your XML, don't you? IIUC you can tie your components to that. And about b) I'm not saying it's not effective or shouldn't be done but I think the idea is to promote the use of utilities, adapters and behaviors instead of "bloating the content class" as it was so badly deemed in AT. That might be a good reason not to have the CT class available as default. Besides it's one less thing to teach/worry about in a first moment, which is good (progressive complexity).

[MrTango]

On ething to keep in mind is, that it's way easier to access a method on a model class/object than trying this with adapters. Adapter are cool for many things but not for all and also cost performance. But more important there is no easy way to add a method to a generic DX item which i can use direcly in a Page Template. A adapter I can only use if I also add a BrowserView which I can then call from a Page Template.

And what are actually the downsides to have a specific model class insted of a generic one? I bet for many of the realworld cases we don't really need the generic approach and can keep things simpler.

[jensens]

:-1: downside if it comes to migrations etc. a generic class is much easier to handle

[MrTango]

in current version (>=3.0.0) of bobtemplates.plone one can choose to have a real content class, as well as they can choose if they want supermodel or zope.schema based models.