Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
PLIP: Fix and Improve Metadata Behaviors #2869
PLIP (Plone Improvement Proposal)
Proposer: Markus Hilbert @iham
Seconder: Jens W. Klein @jensens
Splitting up metadata/dublincore behaviors for higher flexibility and clean up their wrong implementations.
This PLIP targets Plone 6.
Motivation & Assumptions
1.) Wrong Implementation
This needs to be fixed!
2.) Splitting Behaviors
Whenever you want to do anything on one of the most basic fields, you need to remove the
That is a lot of work just for a simple field exchange or small adjustments.
Even for bigger things, like adding a richtext description, interaction with the description (eg for cataloging) it is a lot of boilerplate.
This behavior deals with two cases, which - in our opinion - breaks with the basic idea of behaviors: Doing a small and (hopefully) simple task, being a single or even multiple fields, some functionality or something alike.
The construction of
In addition to that, we could/should have a
Therefore we would need two behaviors. So this would result in
Which are our suggestions for distinct naming.
This is another candidate (even it's not as important as above):
have nothing in common and don't interact besides sharing the same tab (fieldset).
would be beneficial as described for
Proposal & Implementation
Fixing adapter/marker usage
Adapters and markers shall work as expected and as documented in plone.behavior and need to be fixed.
There are probably several places in third party code where
Third party modules depending on the names or schema
Since the Schema names are used by
While I agree with fixing the adapter/marker usage I personally do not like the idea of shipping Plone code with so many granular behaviors.
Also I would like to defend the
Then I perfectly acknowledge the problems that lead to replace
It seems to me that we always want the
The fact that the add and edit view do not require it is a completely different thing.
I hope you see my point here.
Then, as said in the beginning, I perfectly agree that the current behavior implementation needs some love.
The behaviors are all there, but they where bundled in dublincore behavior, which it self had no function.
In case you are talking about the second approache, i still like it more than forcing people to override programatically behaviors, because they are not flexible.
But yeah, i would like to have a more generic solution there too.
If I got this PLIP right, it does want to add new behaviors.
The function of the
If we extremize the "customizability approach" we will end up creating a behavior for each field.
P.s.: I did not get what the HIDE acronym stands for :p