Closed gforcada closed 9 months ago
In my opinion plone.app.content belongs above plone.app.dexterity. plone.app.dexterity is the core content type framework, while plone.app.content is mostly the Classic UI folder contents view. This can probably be resolved by moving INameFromTitle to plone.base, and any other frontend-agnostic functionality from plone.app.content to either plone.app.dexterity or Products.CMFPlone.
Oh, thanks, yes, that makes more sense indeed.
Other than INameFromTitle
the other imports on plone.app.dexterity
are on tests that actually could be moved directly on plone.app.content
itself, as they are testing the functionality of plone.app.content
π€
@davisagli @jensens @mauritsvanrees how does the Proposal
section above in the first comment look like? On my head it makes all sense, and it can be done in small PRs that should not break Jenkins at any point π
@gforcada Makes sense to me, that's what I was thinking too
Sounds good to me.
That's an interesting one π
plone.app.dexterity
It uses the following from
plone.app.content
:i.e. basically a single interface (
INameFromTitle
) and on tests, where is fair game IMHO.plone.app.content
It uses the following from
plone.app.dexterity
:So, two imports mainly:
ICategorization
andIDXFileFactory
, and again, some tests...Proposal
plone.app.content
is meant to be on top ofplone.app.dexterity
, thus a solution can be:INameFromTitle
interface fromplone.app.content
toplone.base
plone.app.dexterity
that importplone.app.content
toplone.app.content
itself (the tests are actually testing functionality fromplone.app.content
)INameFromTitle
imports on bothplone.app.content
andplone.app.dexterity
to useplone.base
, and add a deprecation warning inplone.app.content