From fd3a7bcaf18bcd1ad45364f61281ddc7af681a07 Mon Sep 17 00:00:00 2001 From: gforcada Date: Tue, 3 Oct 2023 16:46:04 +0200 Subject: [PATCH] [fc] Repository: plone.app.dexterity Branch: refs/heads/master Date: 2023-10-03T16:46:04+02:00 Author: Gil Forcada Codinachs (gforcada) Commit: https://github.com/plone/plone.app.dexterity/commit/3d21baecea8f062bca420a64a2f86f5dcfd9fb56 chore: typos Files changed: M docs/advanced/behaviours.rst M docs/advanced/custom-add-and-edit-forms.rst M docs/advanced/vocabularies.rst M docs/behaviors/index.rst M docs/behaviors/intro.rst M docs/behaviors/providing-marker-interfaces.rst M docs/custom-views.rst M docs/intro.rst M docs/schema-driven-types.rst M docs/testing/integration-tests.rst --- last_commit.txt | 58 +++++++++++++++---------------------------------- 1 file changed, 17 insertions(+), 41 deletions(-) diff --git a/last_commit.txt b/last_commit.txt index 13f325f3dc..5b2345b27b 100644 --- a/last_commit.txt +++ b/last_commit.txt @@ -1,48 +1,24 @@ -Repository: plone.scale +Repository: plone.app.dexterity Branch: refs/heads/master -Date: 2023-10-03T14:45:24+02:00 -Author: David Glick (davisagli) -Commit: https://github.com/plone/plone.scale/commit/e8dbc430141052e67a9043f7b5be982f30318c0e +Date: 2023-10-03T16:46:04+02:00 +Author: Gil Forcada Codinachs (gforcada) +Commit: https://github.com/plone/plone.app.dexterity/commit/3d21baecea8f062bca420a64a2f86f5dcfd9fb56 -Fix KeyErrors in ScalesDict conflict resolution +chore: typos Files changed: -M plone/scale/storage.py - -b'diff --git a/plone/scale/storage.py b/plone/scale/storage.py\nindex d08a31b..3e4ac1d 100644\n--- a/plone/scale/storage.py\n+++ b/plone/scale/storage.py\n@@ -104,7 +104,7 @@ def _p_resolveConflict(self, oldState, savedState, newState):\n del saved[key]\n else:\n # modified by saved, deleted by new\n- self.raise_conflict(saved[key], new[key])\n+ self.raise_conflict(saved[key], key)\n for key in added:\n if key in saved:\n # added by saved, added by new\n@@ -116,7 +116,7 @@ def _p_resolveConflict(self, oldState, savedState, newState):\n for key in modified:\n if key not in saved:\n # deleted by saved, modified by new\n- self.raise_conflict(saved[key], new[key])\n+ self.raise_conflict(key, new[key])\n elif saved[key]["modified"] != old[key]["modified"]:\n # modified by saved, modified by new\n self.raise_conflict(saved[key], new[key])\n' - -Repository: plone.scale - - -Branch: refs/heads/master -Date: 2023-10-03T14:49:01+02:00 -Author: David Glick (davisagli) -Commit: https://github.com/plone/plone.scale/commit/7fc5c3f5624ddb46fdf4658756ddf4ee278acfc4 - -changelog - -Files changed: -A news/84.bugfix - -b'diff --git a/news/84.bugfix b/news/84.bugfix\nnew file mode 100644\nindex 0000000..6b047a3\n--- /dev/null\n+++ b/news/84.bugfix\n@@ -0,0 +1 @@\n+Fix KeyError in ScalesDict conflict resolution. @davisagli\n' - -Repository: plone.scale - - -Branch: refs/heads/master -Date: 2023-10-03T16:32:46+02:00 -Author: David Glick (davisagli) -Commit: https://github.com/plone/plone.scale/commit/4f4d6703b755b734a1850e1f9c0b753c005318cc - -Merge pull request #84 from plone/fix-conflict-res - -Fix KeyErrors in ScalesDict conflict resolution - -Files changed: -A news/84.bugfix -M plone/scale/storage.py - -b'diff --git a/news/84.bugfix b/news/84.bugfix\nnew file mode 100644\nindex 0000000..6b047a3\n--- /dev/null\n+++ b/news/84.bugfix\n@@ -0,0 +1 @@\n+Fix KeyError in ScalesDict conflict resolution. @davisagli\ndiff --git a/plone/scale/storage.py b/plone/scale/storage.py\nindex d08a31b..3e4ac1d 100644\n--- a/plone/scale/storage.py\n+++ b/plone/scale/storage.py\n@@ -104,7 +104,7 @@ def _p_resolveConflict(self, oldState, savedState, newState):\n del saved[key]\n else:\n # modified by saved, deleted by new\n- self.raise_conflict(saved[key], new[key])\n+ self.raise_conflict(saved[key], key)\n for key in added:\n if key in saved:\n # added by saved, added by new\n@@ -116,7 +116,7 @@ def _p_resolveConflict(self, oldState, savedState, newState):\n for key in modified:\n if key not in saved:\n # deleted by saved, modified by new\n- self.raise_conflict(saved[key], new[key])\n+ self.raise_conflict(key, new[key])\n elif saved[key]["modified"] != old[key]["modified"]:\n # modified by saved, modified by new\n self.raise_conflict(saved[key], new[key])\n' +M docs/advanced/behaviours.rst +M docs/advanced/custom-add-and-edit-forms.rst +M docs/advanced/vocabularies.rst +M docs/behaviors/index.rst +M docs/behaviors/intro.rst +M docs/behaviors/providing-marker-interfaces.rst +M docs/custom-views.rst +M docs/intro.rst +M docs/schema-driven-types.rst +M docs/testing/integration-tests.rst + +b'diff --git a/docs/advanced/behaviours.rst b/docs/advanced/behaviours.rst\nindex fbd4a1dc..25735f26 100644\n--- a/docs/advanced/behaviours.rst\n+++ b/docs/advanced/behaviours.rst\n@@ -3,7 +3,7 @@ Using behaviors\n \n **Finding and adding behaviors**\n \n-Dexterity introduces the concept of *behaviors* \xe2\x80\x93 re-usable bundles of\n+Dexterity introduces the concept of *behaviors* \xe2\x80\x93 reusable bundles of\n functionality and/or form fields which can be turned on or off on a\n per-type basis.\n \ndiff --git a/docs/advanced/custom-add-and-edit-forms.rst b/docs/advanced/custom-add-and-edit-forms.rst\nindex 7a7e6731..10be03cd 100644\n--- a/docs/advanced/custom-add-and-edit-forms.rst\n+++ b/docs/advanced/custom-add-and-edit-forms.rst\n@@ -91,7 +91,7 @@ it needs to know which ``portal_type`` to use.\n \n You should realise that the FTIs in the ``portal_types`` tool can be\n modified through the web.\n-It is even possible to create new types through the web that re-use existing\n+It is even possible to create new types through the web that reuse existing\n classes and factories.\n \n For this reason, add forms are looked up via a namespace traversal\ndiff --git a/docs/advanced/vocabularies.rst b/docs/advanced/vocabularies.rst\nindex 36fa58af..66c98460 100644\n--- a/docs/advanced/vocabularies.rst\n+++ b/docs/advanced/vocabularies.rst\n@@ -224,7 +224,7 @@ Named vocabularies\n ~~~~~~~~~~~~~~~~~~~~\n \n Context source binders are great for simple dynamic vocabularies.\n-They are also re-usable, since you can import the source from a single location and use it in multiple instances.\n+They are also reusable, since you can import the source from a single location and use it in multiple instances.\n \n Sometimes, however, we want to provide an additional level of decoupling, by using *named* vocabularies.\n These are similar to context source binders,\ndiff --git a/docs/behaviors/index.rst b/docs/behaviors/index.rst\nindex da1be4b7..8120d966 100644\n--- a/docs/behaviors/index.rst\n+++ b/docs/behaviors/index.rst\n@@ -1,7 +1,7 @@\n Behaviors\n ==========\n \n-**How to create re-usable behaviors for Dexterity types**\n+**How to create reusable behaviors for Dexterity types**\n \n .. toctree::\n :maxdepth: 2\ndiff --git a/docs/behaviors/intro.rst b/docs/behaviors/intro.rst\nindex 163c9b71..976a6917 100644\n--- a/docs/behaviors/intro.rst\n+++ b/docs/behaviors/intro.rst\n@@ -5,7 +5,7 @@ Introduction\n \n This manual should teach you everything you need to know to write your own behaviors, but not how to integrate them into another framework.\n \n-*Behaviors* are re-usable bundles of functionality that can be enabled or disabled on a per-content type basis.\n+*Behaviors* are reusable bundles of functionality that can be enabled or disabled on a per-content type basis.\n Examples might include:\n \n - A set of form fields (on standard add and edit forms),\n@@ -17,8 +17,8 @@ You would typically not write a behavior as a one-off.\n Behaviors are normally used when:\n \n - You want to share fields and functionality across multiple types easily.\n- Behaviors allow you to write a schema and associated components (e.g. adapters, event handlers, views, viwelets) once and re-use them easily.\n-- A more experienced developer is making functionality available for re-use by less experienced integrators.\n+ Behaviors allow you to write a schema and associated components (e.g. adapters, event handlers, views, viwelets) once and reuse them easily.\n+- A more experienced developer is making functionality available for reuse by less experienced integrators.\n For example, a behavior can be packaged up and release as an add-on product.\n Integrators can then install that product and use the behavior in their own types, either in code or through-the-web.\n \ndiff --git a/docs/behaviors/providing-marker-interfaces.rst b/docs/behaviors/providing-marker-interfaces.rst\nindex 6e4ade79..0c21295c 100644\n--- a/docs/behaviors/providing-marker-interfaces.rst\n+++ b/docs/behaviors/providing-marker-interfaces.rst\n@@ -65,7 +65,7 @@ The ZCML registration looks like this:\n />\n \n Notice the use of the *AnnotationStorage* factory.\n-This is a re-usable factory that can be used to easily create behaviors from schema interfaces that store their values in annotations.\n+This is a reusable factory that can be used to easily create behaviors from schema interfaces that store their values in annotations.\n We\xe2\x80\x99ll describe this in more detail later.\n We could just as easily have provided our own factory in this example.\n \n@@ -226,6 +226,6 @@ This is quite a complex behavior, but hopefully you can see what\xe2\x80\x99s going on:\n - Similarly, we register a multi-adapter to *IIndexer*, as provided by *plone.indexer*.\n \n Although this behavior provides a lot of functionality, it is no more difficult for integrators to use than any other:\n-they would simply list the behavior interface (*iz.behaviors.reviewers.IReviewers* in this case) in the FTI, and all this functionality comes to life. This is the true power of behaviors: developers can bundle up complex functionality into re-usable behaviors, which can then be enabled on a per-type basis by integrators (or the same developers in lazier moments).\n+they would simply list the behavior interface (*iz.behaviors.reviewers.IReviewers* in this case) in the FTI, and all this functionality comes to life. This is the true power of behaviors: developers can bundle up complex functionality into reusable behaviors, which can then be enabled on a per-type basis by integrators (or the same developers in lazier moments).\n \n .. _plone.pony: http://pypi.python.org/pypi/plone.pony\ndiff --git a/docs/custom-views.rst b/docs/custom-views.rst\nindex 02ef8b16..604536f3 100644\n--- a/docs/custom-views.rst\n+++ b/docs/custom-views.rst\n@@ -206,7 +206,7 @@ Display view\n In the previous section, we created a browser view.\n This kind of view is the most common.\n Sometimes we want to make use of the widgets and information in the type\xe2\x80\x99s schema more directly.\n-For example to invoke transforms or re-use more complex HTML.\n+For example to invoke transforms or reuse more complex HTML.\n \n To do this, you can use a *display view*.\n This is really just a view base class that knows about the schema of a type.\ndiff --git a/docs/intro.rst b/docs/intro.rst\nindex a5fb1414..cbdf73a3 100644\n--- a/docs/intro.rst\n+++ b/docs/intro.rst\n@@ -29,7 +29,7 @@ For administrators and integrators, Dexterity offers:\n \n * the ability to create new content types through-the-web\n * the ability to switch on/off various aspects (called "behaviors") on a per-type basis\n-* improved collaboration between integrators (who may define a type\'s schema, say) and programmers (who may provide re-usable behaviors that the administrator can plug in).\n+* improved collaboration between integrators (who may define a type\'s schema, say) and programmers (who may provide reusable behaviors that the administrator can plug in).\n \n For developers, Dexterity promises:\n \n@@ -45,13 +45,13 @@ Dexterity is an alternative to Archetypes, Plone\'s venerable content type framew\n Some of the main differences include:\n \n * Dexterity is able to leverage many technologies that come with newer versions of CMF and Zope 3. This means that the Dexterity framework contains significantly less code than Archetypes. Dexterity also has better automated test coverage.\n-* Dexterity is more modular where Archetypes is more monolithic. This promises to make it easier to support things like SQL database-backed types, alternative workflow systems, instance-specific sub-types and so on. It also means that many of the components developed for Dexterity, such as the through-the-web schema editor, the "behaviors" system, or the forms construction API (plone.autoform) are re-usable in other contexts, e.g. to build standalone forms or even to augment existing Archetypes-based types.\n+* Dexterity is more modular where Archetypes is more monolithic. This promises to make it easier to support things like SQL database-backed types, alternative workflow systems, instance-specific sub-types and so on. It also means that many of the components developed for Dexterity, such as the through-the-web schema editor, the "behaviors" system, or the forms construction API (plone.autoform) are reusable in other contexts, e.g. to build standalone forms or even to augment existing Archetypes-based types.\n * Archetypes has its own Schema implementation which is incompatible with the interface-based approached found in zope.interface and zope.schema. The latter is used throughout the Zope stack to describe components and build forms. Various techniques exist to bridge the Archetypes schema to the Zope 3 schema notation, but none are particularly attractive.\n * Archetypes uses accessor and mutator methods to get/set values. These are generated and scribbled onto a class at startup. Dexterity uses attribute notation, so whereas in Archetypes you may write context.getFirstName(), in Dexterity you would write context.first_name.\n-* Archetypes has its own implementation of fields and widgets. It is difficult to re-use these in standalone forms or templates, because they are tied to the idea of a content object. Dexterity uses the de-facto standard z3c.form library instead, which means that the widgets used for standalone forms are the same as those used for content type add- and edit forms.\n+* Archetypes has its own implementation of fields and widgets. It is difficult to reuse these in standalone forms or templates, because they are tied to the idea of a content object. Dexterity uses the de-facto standard z3c.form library instead, which means that the widgets used for standalone forms are the same as those used for content type add- and edit forms.\n * Archetypes does not support add forms. Dexterity does, via z3c.form. This means that Dexterity types do not need to use the portal_factory hack to avoid stale objects in content space, and are thus significantly faster and less error prone.\n * Archetypes requires a chunk of boilerplate in your product\'s initialize() method (and requires that your package is registered as a Zope 2 product) and elsewhere. It requires a particular sequence of initialisation calls to register content classes, run the class generator to add accessors/mutators, and set up permissions. Dexterity does away with all that boilerplate, and tries to minimise repetition.\n-* It is possible to extend the schemata of existing Archetypes types with the archetypes.schemaextender product, although this adds some performance overhead and relies on a somewhat awkward programming technique. Dexterity types were built to be extensible from the beginning, and it is possible to declaratively turn on or off aspects of a type (such as Dublin Core metadata, locking support, ratings, tagging, etc) with re-usable "behaviors".\n+* It is possible to extend the schemata of existing Archetypes types with the archetypes.schemaextender product, although this adds some performance overhead and relies on a somewhat awkward programming technique. Dexterity types were built to be extensible from the beginning, and it is possible to declaratively turn on or off aspects of a type (such as Dublin Core metadata, locking support, ratings, tagging, etc) with reusable "behaviors".\n * Dexterity is built from the ground up to support through-the-web type creation. There are products that achieve the same thing with Archetypes types, but they have to work around a number of limitations in the design of Archetypes that make them somewhat brittle or slow. Dexterity also allows types to be developed jointly through-the-web and on the filesystem. For example, a schema can be written in Python and then extended through the web.\n \n As of version 5 of Plone, Dexterity is the preferred way of creating content types.\ndiff --git a/docs/schema-driven-types.rst b/docs/schema-driven-types.rst\nindex 56cd6ccc..32c71ce8 100644\n--- a/docs/schema-driven-types.rst\n+++ b/docs/schema-driven-types.rst\n@@ -317,7 +317,7 @@ The important lines here are:\n The default ``cmf.AddPortalContent`` should be used unless you configure a custom permission.\n Custom permissions are converted later in this manual.\n - We add a *behavior*.\n- Behaviors are re-usable aspects providing semantics and/or schema fields.\n+ Behaviors are reusable aspects providing semantics and/or schema fields.\n Here, we add the ``INameFromTitle`` behavior, which will give our content object a readable id based on the ``title`` property. We\xe2\x80\x99ll cover other behaviors later.\n \n The ``Program``, in ``program.xml``, looks like this:\ndiff --git a/docs/testing/integration-tests.rst b/docs/testing/integration-tests.rst\nindex cd22cb24..1a9f3c3d 100644\n--- a/docs/testing/integration-tests.rst\n+++ b/docs/testing/integration-tests.rst\n@@ -11,7 +11,7 @@ very least.\n To help manage test setup, we\xe2\x80\x99ll make use of the Zope test runner\xe2\x80\x99s\n concept of *layers*.\n Layers allow common test setup (such as configuring a Plone site and\n-installing a product) to take place once and be re-used by multiple test\n+installing a product) to take place once and be reused by multiple test\n cases.\n Those test cases can still modify the environment, but their changes will be\n torn down and the environment reset to the layer\xe2\x80\x99s initial state between\n'