Better dexterity content type skeleton

[kagesenshi]

Changes:

• I've got rid of the custom content type class usage as it is more flexible to use dexterity.Item/dexterity.Container directly. The original reason i created the custom content class usage back in collective.dexteritypaste (which later become zopeskel.dexterity) was mainly due to I had some Archetype assumption that content class is needed, but after doing several projects on dexterity, i discovered that this is unnecessary. Furthermore, not using custom content class gives the benefit of easier refactoring as the zodb content object is not coupled to the custom content class
• I replaced the SampleView with a default view based on dexterity.DisplayForm and plone.app.dexterity item default view. This makes it easier to immediately customize the default view of the content type. dexterity.DisplayForm also provides a way to easily render existing widgets.
• the buildout is now updated to extend the test buildout from collective/buildout. that way it will always use the latest plone4 release buildout.

[cewing]

@smcmahon, do you have any opinions on this one? Could you take some time and review this in the next couple of days?

[cewing]

@kagesenshi would you mind adding some notes to the changelog for this? That would be most helpful.

[davisagli]

Actually I think it's better to generate a custom content type class, because then you have it if you decide your type needs some custom logic in the future. If it is an Item or Container you would need to write a migration to convert the existing content items before that would be possible.

[kagesenshi]

@davisagli , my approach for custom logic for that would be to create an adapter on the content interface .. custom logic is implemented on the adapter instead on the content .. this imo, is more flexible and clean ..

of course, different people have different approach .. probably this need discussion :)

[davisagli]

Sure, that's always preferable. But sometimes you want to customize how field values are get/set or override a method that Plone or Zope expect to find on the content class.

[kagesenshi]

for extending existing content types with fields with custom setter/getter , one can implement as / move the fields to a dexterity behavior adapter ..

[cewing]

templer templates should be examples of the way we want to teach newcomers to work. I think it's important for us to set as few traps as possible for them. Given that, which of these two approaches results in the least pain for the developer down the road? Is that a question that can be answered clearly?

[kagesenshi]

the dexterity manual does not cover the use of custom class , it only suggest to use either dexterity.Item or dexterity.Container .. http://plone.org/products/dexterity/documentation/manual/developer-manual/schema-driven-types/referencemanual-all-pages ..

a setup thats more consistent with the manual is easier for newcomers to follow imo ..

[cewing]

I agree that using classes is not covered by the manual, and I agree that keeping documentation and templer templates in line is a very good idea. However, in this case, I think it might be a deficiency in the documentation. I've run into a number of times when having a custom class has been very helpful. @davisagli, can you weigh in again here? Perhaps opening this to wider discussion on the plone developers list would be of value?

[davisagli]

I haven't personally reached a conclusion as to which is better.

[petri]

@cewing, can you share some cases when a custom class has been helpful? I think that would help us understand the relative benefits and pitfalls. Having said that, I am not sure either way is 'better'. Perhaps it's just that when complexity, reuse requirements and rate of change go up, the adapter-based, custom-class-less approach will pay off more?

In any case, I would like to ask that the 'other' approach be documented as well in the generated code. Perhaps generate both, but just comment out either one. So people would at least be presented the fact that one can work with or without custom content classes (regardless of which approach is used in the generated code).