Ticket #12344 (closed PLIP: fixed)

Opened 4 years ago

Last modified 2 years ago

Switch to Dexterity-based core content types (plone.app.contenttypes)

Reported by: timo Owned by: pbauer
Priority: minor Milestone: 5.0
Component: Backend (Python) Version:
Keywords: Cc:

Description (last modified by timo) (diff)

Proposer: Philip Bauer
Seconder: Timo Stollenwerk

Motivation

Developers are currently using dexterity in the wild. It would be nice if a site had content that used one of the content-frameworks rather than both. (Philip Bauer, Plone Conference 2011)

This package may not be of particular useful to the user since it is matching functionality. However, It will improve the Plone code by pushing for a separation of the content types framework from the core CMS. This should initialize movement towards finding, removing and/or replacing the Archetypes dependency.

Assumptions

  • This package is a drop-in substitution (not a replacement) for ATContentTypes.
  • The Event content type is being addressed in PLIP #10886.

Proposal & Implementation

 https://github.com/plone/plone.app.contenttypes/blob/master/TODO.txt

Deliverables

  • Integration tests
  • Localization
  • Documentation
  • Migration steps

Risks

What are the risks of implementing this proposal?

What incompatibilities can it cause?

This PLIP will make it imposible to have both ATContentTypes types installed along side the plone.app.contenttypes types. Users will need to be made aware that their decision to use this package will make it impossible to revert back to ATContentTypes. Additionally, the user may experience problems integrating some third-party products with these new types.

Participants

  • Philip Bauer (pbauer)
  • Michael Mulich (pumazi)
  • Timo Stollenwerk (timo)
  • Peter Holzer (agitator)

See also  https://github.com/plone/plone.app.contenttypes/blob/master/README.txt

Progress

Work is being done at  https://github.com/plone/plone.app.contenttypes

Change History

comment:1 Changed 4 years ago by kleist

Please use  http://dev.plone.org/wiki/PLIP as a template, or modify the Type from PLIP to Feature Request. Thanks!

 http://dev.plone.org/wiki/PlipProcess

comment:2 Changed 4 years ago by pumazi

  • Description modified (diff)

comment:3 Changed 4 years ago by pumazi

  • Description modified (diff)

comment:4 Changed 4 years ago by pumazi

  • Description modified (diff)

comment:5 Changed 4 years ago by pumazi

  • Description modified (diff)

comment:6 Changed 4 years ago by pumazi

  • Description modified (diff)

comment:7 Changed 4 years ago by eleddy

  • Status changed from new to confirmed
  • Version set to 4.1
  • Component changed from Unknown to Bounty Mission
  • Milestone set to 4.4

comment:8 Changed 4 years ago by eleddy

  • Status changed from confirmed to closed
  • Component changed from Bounty Mission to Backend (Python)
  • Resolution set to fixed

comment:9 follow-up: ↓ 10 Changed 4 years ago by davisagli

  • Status changed from closed to reopened
  • Resolution fixed deleted

Not sure why this got marked closed.

comment:10 in reply to: ↑ 9 Changed 4 years ago by eleddy

Replying to davisagli:

Not sure why this got marked closed.

That was an accident. Thanks for reopening!

comment:11 Changed 4 years ago by eleddy

this is most definitely approved, but we aren't sure what release yet. davisagli will be your plip champion and help you with thi

comment:12 Changed 3 years ago by davisagli

  • Status changed from reopened to confirmed
  • Version 4.1 deleted
  • Milestone changed from 4.4 to 4.x

Any update on the implementation status? Is the sprint to work on this going to happen?

comment:13 Changed 3 years ago by timo

The sprint in Munich in January is going to happen and will be announced soon. I will keep you posted...

comment:14 Changed 3 years ago by timo

  • Description modified (diff)

comment:15 Changed 3 years ago by timo

Just a quick update what we did during the Munich beer and wine sprint:

Details can be found here:

 http://titanpad.com/etVw3qUlkF

Next steps:

  • Philip and I are going to update the PLIP and we are going to submit it to the fwt afterwards.

Questions:

  • Is this something that might be considered for inclusion into Plone 4.4? Not sure if this makes sense but it would be good to know if we need to hurry with the final polishing. We are fine with shipping p.a.contenttypes as an add-on product first though.

comment:16 Changed 3 years ago by thet

i have put my review in the 4.4 branch of buildout coredev. see it here:

 https://github.com/plone/buildout.coredev/blob/4.4/plips/reviews/plip12344-review-thet.rst

comment:17 follow-up: ↓ 24 Changed 3 years ago by timo

Hi Johannes,

thanks for your detailed review. Here are my replies.

Code Reviewing Remarks


There seems a lot more than 200 test cases, which is good. I don't know about the test coverage yet.

Test Coverage is currently 93 %:

Name                                                    Stmts   Miss  Cover   Missing
-------------------------------------------------------------------------------------
plone/app/contenttypes/__init__                             2      0   100%   
plone/app/contenttypes/behaviors/__init__                   0      0   100%   
plone/app/contenttypes/behaviors/leadimage                 17      1    94%   35
plone/app/contenttypes/behaviors/viewlets                   9      0   100%   
plone/app/contenttypes/browser/__init__                     0      0   100%   

plone/app/contenttypes/browser/link_redirect_view          25     12    52%   28-58
plone/app/contenttypes/browser/migration                   92     53    42%   4-5, 45-46, 84-141, 144-158, 161-165
plone/app/contenttypes/browser/utils                       21      0   100%   
plone/app/contenttypes/content                             18      0   100%   
plone/app/contenttypes/indexers                            24      0   100%   
plone/app/contenttypes/interfaces                          11      0   100%   
plone/app/contenttypes/migration                          135     13    90%   34-35, 55, 73-74, 80-81, 126, 146, 167, 183, 204, 216
plone/app/contenttypes/schema/__init__                      0      0   100%   
plone/app/contenttypes/setuphandlers                      168     44    74%   47, 54-56, 66, 74, 78, 86-87, 100, 143-144, 148, 154, 157-158, 162-163, 184-188, 197, 201-202, 217, 226-232, 246, 261, 270-276, 292, 305-306, 312-313, 323-324
plone/app/contenttypes/testing                             26      0   100%   
plone/app/contenttypes/tests/__init__                       0      0   100%   
plone/app/contenttypes/tests/test_acceptance               13      0   100%   
plone/app/contenttypes/tests/test_behaviors_leadimage      49      0   100%   
plone/app/contenttypes/tests/test_content_profile          74      0   100%   
plone/app/contenttypes/tests/test_document                 73      0   100%   
plone/app/contenttypes/tests/test_event                    79      0   100%   
plone/app/contenttypes/tests/test_file                     93      0   100%   
plone/app/contenttypes/tests/test_folder                   92      0   100%   
plone/app/contenttypes/tests/test_image                   102      0   100%   
plone/app/contenttypes/tests/test_indexes                  87      0   100%   
plone/app/contenttypes/tests/test_link                     76      0   100%   
plone/app/contenttypes/tests/test_migration               318      0   100%   
plone/app/contenttypes/tests/test_news_item                89      0   100%   
plone/app/contenttypes/tests/test_setup                    26      0   100%   
plone/app/contenttypes/tests/test_upgrade                  62      0   100%   
plone/app/contenttypes/upgrades                            18      0   100%   
-------------------------------------------------------------------------------------
TOTAL                                                    1799    123    93% 

For a more cleaned up code base I suggest to move the XML Schema definitions in a explicit directory called "schemata".

Done.

Instead of implementing the event type yourself, you should use plone.app.event. It's going to be merged into core very soon and the packages are already used in production ( http://pypi.python.org/pypi/plone.app.event). There are some things, which should be backported to plone.app.event - especially the changes to the "Event" folder/collection. Since I'm maintaining plone.app.event, let's keep in contact regarding this.

We discussed this at the Munich sprint and decided to merge p.a.event once its included in Plone core. We already have a branch with p.a.event included:  https://github.com/plone/plone.app.contenttypes/tree/feature/p.a.event

I like the totally simple (when compared to collective.contentleadimage) leadimage behavior implementation. But at first sight I expected more plone.app.contenttype specific behaviors in the behavior subpackage. Also, the leadimage functionality seemed a bit misplaced in plone.app.contenttypes. But then I realized that it's needed for the NewsItem. So it's ok for me.

Yeah. This could be improved once we decide to refactor the standard content types. For now we just use it for the News Item type.

There are folder_full_view and folder_full_view_item views. I have created a new implementation which is going to be merged in a Plone core package soon (when I find the time for it). It fixes the default implementation's inability to render Browser-based views properly and should not have any troubles with dexterity based contents. I suggest to remove your folder_full_view views and use (and fix if necessary) mine. You can find it here until it's merged into plone.app.content or the like:  https://github.com/collective/collective.fullview Is it really necessary to have all contenttype views reimplemented in plone.app.contenttypes? (Thinking out loud:) If yes, we should consider making them generic for DX and AT, make them BrowserView based and put them into plone.app.content. Maybe by using the IAccessor concept introduced and used in plone.app.event/plone.event as IEventAccessor. This might go beyound the scope of this PLIP and touches the responsibility of other PLIPs (13260, 13283). But we should discuss this, since there is some more space for simplifications and improvements.

The problem is that the views in Plone are still skin based. We need BrowserView based views. Once these are merged into Plone we can remove the views from p.a.contenttypes.

I could not find any signs of an upgrade path for AT based Collections to DX based ones (searching in plone.app.collection and plone.app.contenttypes). That should be fixed too.

Our initial idea was not to support any upgrade paths. p.a.contenttypes should just be used to create new Plone sites from the scratch. Though, people started to work on it during the Munich sprint. It should be easy to write an upgrade step for collections though. I'm not sure if it is a good idea to really advertise this. Personally I don't want to put too much effort into this.

When installing the Plone site and choosing the Dexterity Framework, is Archetypes still included as dependency and it's GS installation profile just hidden or is it not included? If it's still in, the GenericSetup profile should be shown, so that integrators can install it, if they need to (e.g. for Addon-Products, which still need Archetypes).

ATContentTypes is still fully installed. We just remove the old types and replace them with the Dexterity-based versions. In the future we might want to remove ATContentTypes entirely.

TTW Remarks


Creating an event leads into an error when redirected to the event view:

URL: /home/thet-data/data/dev/plone/plone.app.contenttypes/plone.app.contenttypes/plone/app/contenttypes/browser/event.pt Line 121, Column 32 Expression: <PathExpr standard:u'portal/icon_export_vcal.png'>

Do we really want to look into this? If p.a.contenttypes and p.a.event both go into Plone core we should integrate p.a.event into p.a.contenttypes as soon as possible.

Creating an Image and uploading works, image scales are created, using a custom Title works as well as autogenerating the title from the image name. Only the scale names are cryptic (UUID?). I'm not sure if I should like this. Back then, when I came to Plone, having meaningful image names was a pro criterium for Plone compared to other CMS (e.g. Typo3, which stores all images under cryptic UID names).

I'm afraid I don't understand the problem. The plone.app.imaging scales work as expected " http://localhost:8080/Plone/image.jpg/@@images/image/mini". Where do you see UUIDs?

The folder_summary_view on Plone site root doesn't show NewsItem images, while the "Summary View" in the News folder does. Looks like if on Plone site root the new view isn't used.

I can confirm that problem. I was unable to solve it on short notice though. I tried to register the folder_summary_view for the IPloneSiteRoot/ISiteRoot but that didn't do the trick. I'd say we should look into this when we moved all the skins views in Products.CMFPlone to BrowserViews.

comment:18 Changed 3 years ago by timo

  • Milestone changed from 4.x to 4.4

comment:19 Changed 3 years ago by timo

It just occurred to me that we currently can not use the AT and the DX version of plone.app.collection at the same time (because these are two branches/packages with the same name). Therefore, if we want to be able to choose between AT and DX when creating a Plone site, both versions need to be available.

To accomplish this, we can either merge both implementations into one plone.app.collection package or just move the dexterity plone.app.collection into plone.app.contenttypes.

I think this decision depends on if we want to keep plone.app.collection as a separate package. Even though I have projects where we used plone.app.collection only, I think it does not make sense to have all Plone default types in one package and just exclude the collections from that. That's even more true once p.a.contenttypes becomes a part of Plone core.

Therefore I would recommend to merge the dexterity collection into p.a.contenttypes. When I do so I would also refactor the current collection into a behavior to make it easier to use for integrators (for instance for folderish collections).

Could I get a short feedback from the FWT/reviewers on that?

Last edited 3 years ago by timo (previous) (diff)

comment:21 Changed 3 years ago by timo

Hi Franco,

thanks for your excellent and very detailed review!

I already started to refactor the collection type into a behavior and I will start to merge it into p.a.contenttypes soon.

Personally I won't have the time to look into the migration issues, but I will try to find some people that can look into it.

As Johannes suggested, we will also replace the current event type with a p.a.event-based one.

You will get more detailed answers regarding the other points raised in your review as soon as I find the time to look into it.

Timo

comment:22 Changed 3 years ago by pbauer

Hi Franco and Hannes,

thanks for the very helpfull reviews! I'll be working on p.a.c during Plone Open Garden in Sorrento. I hope to round up some more help so we can fix all issues that are left, especially improving the migration-story.

Philip

comment:23 Changed 3 years ago by pbauer

  • Status changed from confirmed to assigned
  • Owner set to pbauer

comment:24 in reply to: ↑ 17 Changed 3 years ago by thet

hi timo, thanks for the answer. here my follow-up:

first, implementing plone.app.collection as behaviors in plone.app.contenttypes sounds like a good idea!

+1 from my side.

are you going to implement that for folders only or for any content type? any content sounds ground-breaking, but also quite experimental (we would need more flexible views for content types - something like tiles which show different stuff depending on the capabilities defined by behaviors. however, that goes too far for now).

Test Coverage is currently 93 %:

as i'm not too fanatical regarding tests (especially with browser tests), that's enough for and optional core package.

[plone.app.event...]

We discussed this at the Munich sprint and decided to merge p.a.event once its included in Plone core. We already have a branch with p.a.event included:  https://github.com/plone/plone.app.contenttypes/tree/feature/p.a.event

it's in the core 4.4 branch already.

[collective.fullview...]

i'll try to integrate collective.fullview ASAP/this week.

[generic views...]

The problem is that the views in Plone are still skin based. We need BrowserView based views. Once these are merged into Plone we can remove the views from p.a.contenttypes.

agreed.

URL: /home/thet-data/data/dev/plone/plone.app.contenttypes/plone.app.contenttypes/plone/app/contenttypes/browser/event.pt Line 121, Column 32 Expression: <PathExpr standard:u'portal/icon_export_vcal.png'>

Do we really want to look into this? If p.a.contenttypes and p.a.event both go into Plone core we should integrate p.a.event into p.a.contenttypes as soon as possible.

agreed, better use plone.app.event

Creating an Image and uploading works, image scales are created, using a custom Title works as well as autogenerating the title from the image name. Only the scale names are cryptic (UUID?). I'm not sure if I should like this. Back then, when I came to Plone, having meaningful image names was a pro criterium for Plone compared to other CMS (e.g. Typo3, which stores all images under cryptic UID names).

I'm afraid I don't understand the problem. The plone.app.imaging scales work as expected " http://localhost:8080/Plone/image.jpg/@@images/image/mini". Where do you see UUIDs?

i confirm, " http://localhost:8080/Plone/image.jpg/@@images/image/mini" works as expected.

newsitem.pt and folder_summary_view.pt both use cryptic scale names, which look like UUIDs. looks like,

            <img tal:define="scale context/@@images"
                 tal:replace="structure python: scale.scale('image',
                              scale='mini').tag(css_class='newsImage')" />

produces them, which comes from plone.app.imaging (resp. any dexterity implementation of the @@images browser:page, which i could not find quickly).

The folder_summary_view on Plone site root doesn't show NewsItem images, while the "Summary View" in the News folder does. Looks like if on Plone site root the new view isn't used.

I can confirm that problem. I was unable to solve it on short notice though. I tried to register the folder_summary_view for the IPloneSiteRoot/ISiteRoot but that didn't do the trick. I'd say we should look into this when we moved all the skins views in Products.CMFPlone to BrowserViews.

i also have had this problem in collective.folderishtypes and could not solve it. i'd say, ignore it for p.a.contenttypes but let's keep it in mind for later. i created a ticket for this: https://dev.plone.org/ticket/13497

Last edited 3 years ago by thet (previous) (diff)

comment:25 Changed 3 years ago by timo

are you going to implement that for folders only or for any content type? any content sounds ground-breaking, but also quite experimental (we would need more flexible views for content types - something like tiles which show different stuff depending on the capabilities defined by behaviors. however, that goes too far for now).

For now my plan is just to factor out the collection functionality into a behavior and then make the "Collection"-type (which is still non-folderish) provide that behavior. So nothing really changes. It just gives integrators more flexibility to re-use the collection behavior or implement their own folderish collection types if they want. The plan is still to provide a 1:1 replacement for ATContentTypes, nothing more.

I don't want this PLIP to be slowed down by the folderish vs. non-folderish debate. I would prefer if we would finish the PLIP and then decide if we want to move to folderish types (in addition to the original PLIP). If we don't keep those two issues separated I'm afraid we could loose momentum.

comment:26 Changed 3 years ago by thet

perfect. i had the association that collections are folderish, which is wrong.

regarding folderish vs non-folderish: folderish types have some UI issues you cannot address within your PLIP easily. no advice from my side, so keep on your work as planned.

comment:27 Changed 3 years ago by davisagli

Regarding the UUID-based URLs for image scales: I think that is an intentional design decision; it's a hash of the scale parameters so they can be cached permanently. The name-based URLs still work but may require cache purging, so are not generated by the scaling API.

comment:28 Changed 3 years ago by timo

Here is a summary on what I did so far (for the folks that plan to work on it during the Sorrento sprint):

I also tried to include p.a.event but that did not worked out. Maybe I did something wrong.

with p.a.event latest release::

Plenty of "ConfigurationConflictError" between p.a.event and plone core packages. Shouldn't p.a.event use its own browser layer to avoid those?

with p.a.event master::

ImportError: cannot import name is_date

comment:29 Changed 3 years ago by pbauer

I propose we use plone.app.widgets in plone.app.contenttypes. This way the use of p.a.c. actually improves the enduser-experience compared to the old types.

I created a branch 'widgets' { https://github.com/plone/plone.app.contenttypes/tree/widgets). It works like a charm and all test pass except for one in our event-type (that we want to drop anyway).

That means we'd depend on PLIP13476 (https://dev.plone.org/ticket/13476) that also aims at Plone 4.4

There is still some work to be done for this to be finalized (e.g. using the new widgets in collections), but most of it is not the job of this PLIP...

comment:30 Changed 3 years ago by pbauer

After manually ripping out the whole ical-import-stuff I was able to get them working together well.

Would it be better to include plone.app.event into plone.app.contenttypes like we did with plone.app.collection? Or should we just wait for a new release of plone.app.event and then remove our old event-type and make 'plone.app.event [ploneintegration,dexterity]' a dependency for p.a.c?

comment:31 Changed 3 years ago by thet

@pbauer @timo i'll have a look at the plone.app.event integration troubles. but - the changes in master branch i'm working on are not released yet. the ical import stuff depends on source checkouts of icalender, plone.event and plone.app.event. in case you want to depend on the latest sources, extend your buildout with:  https://github.com/plone/plone.app.event/blob/master/sources.cfg

@timo, regarding configuration conflicts - sounds like you're not using the Products.CMFPlone master branch source checkout. in that case you should depend on 'plone.app.event [ploneintegration,dexterity]' and have the ploneintegration profile imported, as @pbauer mentioned.

Last edited 3 years ago by thet (previous) (diff)

comment:32 Changed 3 years ago by pbauer

@thet regarding configuration conflicts: We have our own branch of Products.CMFPlone we'll have to rebase to use the current master. But these problems do not arise when I use the plone.app.event master (except for the ical-stuff).

What do you think about merging the packages or moving the dx-part of plone.app.event to p.a.c like we did with plone.app.collections? I don't a have a strong opinion as long as we can get rid of the the dx-event-type of p.a.c.

comment:33 Changed 3 years ago by davisagli

For plone.app.collection there was a good reason to move it into plone.app.contenttypes (we need to have both implementations present to let the admin decide which content type system to use, and before the Dexterity implementation of collections was in a branch of plone.app.collection so you could only have it xor the Archetypes one). But for plone.app.event I don't see any reason to move it into plone.app.contenttypes when it's already set up to function nicely as a separate, optional package.

comment:34 Changed 3 years ago by pbauer

I put my efforts to integrate plone.app.event in the branch new 'event'. It uses  https://github.com/plone/plone.app.event/blob/master/sources.cfg for checkouts needed for plone.app.event.

It works well but now we need migrations for:

  • ATEvent to plone.app.event
  • p.a.c.-Event to plone.app.event

I think we'll get them done tomorrow and will put them in plone.app.contenttypes for the time being.

comment:35 Changed 3 years ago by thet

there is a upgrade step for ATCT based ATEvents to p.a.e based ATEvents, if that helps.

it's upgrade_step_1 here:  https://github.com/plone/plone.app.event/blob/master/plone/app/event/at/upgrades/event.py

comment:36 Changed 3 years ago by pbauer

That's very helpful, I totally missed it looking through the code.

Now we only need a migration from p.a.c.-Event to plone.app.event since Timo just committed a migration for collections.

comment:37 Changed 3 years ago by timo

I propose we use plone.app.widgets in plone.app.contenttypes. This way the use of p.a.c. actually improves the enduser-experience compared to the old types.

Before we merge the branch I would like to wait until the framework team approves p.a.widgets for 4.4, so we don't have to hold up our PLIP just because p.a.widgets does not get included.

We also agreed that we want to provide the same user experience for AT/DX content types first and then go from there and improve things (after p.a.contenttypes has been included into the core). This is still a very important point in my opinion.

comment:38 Changed 3 years ago by pbauer

@frapell: big thanks for this awesome review. Here is the firsat round of feedback. I created issues in github for issues that I was not able to solve today. I also ommited duplicates.

File

  • AT has a "Location" field under "Categorization" that DX lacks.

The location field is not part at the metadata-behavior in dx. My guess is that was a consious design-decision in dexterity. We could add this to all types (it is only a stringfield) but I'd like to hear from the framework-team if this is really wanted.

  • AT has "Allow comments" that DX lacks.

That can be enabled/disabled in the type-configuration ( http://localhost:8080/Plone/dexterity-types/Document/@@behaviors). When it is enabled for a type there is a "Allow discussion"-Field in the edit-form.

  • AT generates its title from filename, DX doesn't.

True. Same for Images. I'll add it as a issue.

  • When adding a content as related, the DX version doesn't show it in the view template.

This is fixed in  https://github.com/plone/plone.app.layout/commit/76efeb20cf1d4bf6ae3031e926bc47110dd95378

  • When clicking the "View" tab you don't go to the "/view" view (bug?).

I have just never met a use-case for this. It could be easily changed (by adding '/view' to the url_expr of the action) I just doubt it serves any purpose (with collections it does not work since view is a 'zope.traversing.namespace.view object at ...'). I created a issue.

  • DX version allows to setup content rules, where AT doesn't.

As far as I can see they allow to do that now (I'm using 4.3rc1).

Folder

  • AT version has an extra view template: "Thumbnail view"

That view seems to have been renamed to "Album" but is still atct_album_view.

  • AT Version provides possibility to restrict which contents are addable. DX version needs to enable a behavior for that, should it be enabled by default?

This has beed done as a behavior Products.CMFPlone.interfaces.constrains.ISelectableConstrainTypes. I added it to the folders.

Image

  • DX version allows to change the default view and AT doesn't. When choosing "View Image Fullscreen", you can no longer see the green edit bar.

Fixed. That view should not have been exposed to the end-user.

  • AT provides a "Transform" tab that allows basic image manipulation. DX doesn't.

True. Issue added.

News Item

  • AT has a "Change note" that the DX lacks.

I merged a branch I made two years ago and versioning is enabled and working now. Another issue is that fields acquired from behaviors are versioned but not shown in the diff-view. That has to be adressed in collective.dexteritydiff.

Document

  • AT has "Presentation mode"

The presentation mode has been moved to plone.app.s5slideshow. The package is discussed in https://dev.plone.org/ticket/13270. That could be extended to also provide a behavior for this mode. Issue added.

  • "Table of contents", that DX lacks.

Issue added

  • DX allows to use variables like "navigation_root_url" and "portal_url" that get later expanded to create the full url, however, the "view" template shows the link with the variable (ie. ${navigation_root_url}/something) even thought, when you hover the link, you see the proper url with the variable expanded.

I think that is a great feature and we use it in a lot of sites. But I'll be happy to move it into a branch if you agree that this should not be shipped. Issue added.

comment:39 Changed 3 years ago by pbauer

@frapell: Here comes part II of the reply to your review.

  • The labels widget in the AT content types displays existing labels that are selectable through a checkbox, existing labels, and possibility to add new ones. DX widget, is just a textarea.

That will be fixed by https://dev.plone.org/ticket/13476. I don't think we'll have a solution for this when that PLIP is not approved.

  • The "allow comments" checkbox gets fixed when enabling the proper behavior. Should this behavior be enabled by default?

Done

  • Going to the "Types" tool and changing the "versioning policy" appears to have no effect (Unless p.a.versioningbehavior is installed and configured)

Fixed (see above)

  • The "Change note" (Versioning), gets solved by adding "plone.app.versioningbehavior" and enabling the behavior. Should this be included and enabled by default?

Done

  • Had to add "collective.dexteritydiff", in order to be able to see diffs, however, it doesn't show any diff with different versions.

Fixed

  • PEP8/PyFlakes

We now flake/lint/pep8 the code before every commit and it should be ok now.

  • Migration

We're still working on this but I fixed most migration-issues today and was able to migrate sites fully or partially. There are still issues that we'll work on (UI, Feedback after migrations, Documentation, Tests). More feedback from you (or anyone) is much appreciated.

  • Trying to create a Plone Site from scratch choosing "Archetypes"

I got this to work now although there are still some issues to be solved, like forcing the installation of plone.app.collections (AT) when choosing Archetypes ( https://github.com/plone/Products.CMFPlone/commit/6c5312e3d401b9fd2643e3c11227e7d8cbb07b0a)

comment:40 Changed 3 years ago by pbauer

Some things to consider: Should we have a forced upgrade-step migrating all the content? There are severals options and several use-cases that have to be considered:

Should we do:

Schemaextended content is not likely automatically migrateable. Currently we don't migrate them but give a warning. Except if file and image since the blob-falvors are extended but need to be migrated.

We could also not remove AT-based types but rename and disable "implicity addable", so they could still be editied but no longer added. We'd need to do some of this in setuphandlers.py and not the types.xml as it happens now.

Which framework should be default in the site-creation-form DX or AT. I'd actually prefer having DX the default and moving the choice to a advanced-view.

comment:41 follow-up: ↓ 42 Changed 3 years ago by thet

ask me, and i'd say: AT should be kept the default in Plone 4.x. DX would be the default in Plone 5.x then. we should not force any upgrades. (even in Plone 5, where people can still depend on P.ATCT, if they upgrade from Plone 4.)

i understand, that schemaextended types cannot be easily migrated and putting effort to this would be a waste of time. considering this, our only option is to not force-upgrade any AT content to DX, otherwise it would be quite confusing and inconsequently.

in my experience, schemaextended types are totally wide-spread, for a good reason. so the upgrade path is more like an example to copy from in most cases. so i thought that maybe we should understand the upgrade scripts more like an upgrade framework, which developers can use to upgrade their content. developing upgrade scripts for specific schema-extended content should be much easier than developing a generic solution.

Last edited 3 years ago by thet (previous) (diff)

comment:42 in reply to: ↑ 41 Changed 3 years ago by timo

Replying to thet:

ask me, and i'd say: AT should be kept the default in Plone 4.x. DX would be the default in Plone 5.x then. we should not force any upgrades. (even in Plone 5, where people can still depend on P.ATCT, if they upgrade from Plone 4.)

This was our roadmap right from the beginning.

i understand, that schemaextended types cannot be easily migrated and putting effort to this would be a waste of time. considering this, our only option is to not force-upgrade any AT content to DX, otherwise it would be quite confusing and inconsequently.

Agreed.

in my experience, schemaextended types are totally wide-spread, for a good reason. so the upgrade path is more like an example to copy from in most cases. so i thought that maybe we should understand the upgrade scripts more like an upgrade framework, which developers can use to upgrade their content. developing upgrade scripts for specific schema-extended content should be much easier than developing a generic solution.

We will never be able to support all upgrade scenarios I guess. As long as p.a.contenttypes is optional, a migration is not even necessary in my opinion. Though, it's good that we have one now which we can improve until (and if) p.a.contenttypes become the default.

comment:43 Changed 3 years ago by timo

The p.a.contenttypes Jenkins job has a new URL:

 http://jenkins.plone.org/job/plone-app-contenttypes/

(Includes PEP8/CSSLint/JSLint code analysis and test coverage; job is marked unstable when there is a single PEP8 violation or test coverage drops below 90%; there is also a git pre-commit hook installed that complains when new violations are introduced into the repo).

comment:44 Changed 3 years ago by timo

comment:45 Changed 3 years ago by esteele

  • Milestone changed from 4.4 to 5.0

The Framework Team has decided to move on to Plone 5. Updating milestones accordingly.

comment:46 Changed 2 years ago by davisagli

  • Status changed from assigned to closed
  • Resolution set to fixed
  • Summary changed from Factor out Products.ATContentTypes dependency from Products.CMFPlone to Switch to Dexterity-based core content types (plone.app.contenttypes)

This has been merged for Plone 5.

Note: See TracTickets for help on using tickets.