Hi I like your idea. Also as a non bootstraper, I experienced similar cases. "Inventing" new plugins, with the same model attached, thus being able to structure things correctly (and users not being able to drag and drop an image into another context, because it is a different plugin, for the system).
But, in 95% of the cases, I dont need it...so, up to you :-) Ben On Sunday, 29 October 2017 22:48:40 UTC+1, czpython wrote: > > Moved from https://github.com/divio/django-cms/issues/6110 > > > Preamble > > We should rethink the way how to handle the methods to determine which > Plugin is eligible to become a child of another plugin. > > > Currently, when we open the CMS in structure mode, the Placeholder and its > attached Plugins know which plugins may be added as children to an existing > plugin. This is determined by each plugin through its attributes > parent_plugins and child_plugins. These attributes may be either None or > a list of strings. In the former case, all plugins are allowed as > parent/children, > whereas in the latter case, only the named plugins are eligible as > parents/children. > > > > This static assignment has some drawbacks > > 1. > > In an ecosystem of plugins from different vendors, beforehand we don't > know, who may want to become the child of a plugin from another vendor. > This could cause one vendor having to as another vendor to add his plugin > to the list of allowed children. > 2. > > Computing the eligible parent-children relationships is time > consuming. Therefore django-CMScaches this information internally, > which removes the possibility to determine dynamically, for instance by > evaluating the current context, which children plugins can be added to an > existing plugin. > 3. > > In structure mode, when rendering a deep tree of plugins, each plugin > comes with its own list of eligible children plugins. This can add many > kilobytes of additional data to the payload, when transferring a CMS page > in structure mode. > 4. > > This rigid system of parent-children relationships, does for instance > not allow to add kinds of intermediate plugins, such as wrappers or > logical > segments. > > Therefore I want to propose a different method to determine which plugins > are allowed as children of another plugin. Instead of computing this list > statically *before* the CMS page is rendered, we should add a REST > endpoint, which computes this relationship dynamically and based on the > current context. > > > This list then is transferred from the server to the client and is used to > render a list of possible > children plugins. The computation of this list should work as follows: > > - The plugin being asked for, iterates over all plugins registered in > the pool. > - It then invokes a method, say allowed_as_child_of() for each of the > plugins of the pool, > passing its own instance and the current context. > - Based on the given parameters, this method returns a boolean, which > determines, whether a plugin can be added to the current plugin or not. > > This computation can now be much more time consuming. This is because we > only have to do it > whenever the user clicks on the + symbol inside the plugin editor, rather > than having > to do it for all plugins inside the pool. Even if such a computation > requires 200 milliseconds, > since this it is part of the user's interaction, this would disturb. > > > > Possible new Features > > Plugin systems, which map the Bootstrap grid, usually encounter the > following problem: > > A row may be part of a container, and columns may be part of that row. An > accordion, carousel, > panel and similar elements can either be children of the container, the > row or the column. > > Depending below which of these elements an accordion panel is placed, its > own children then > shall either be either rows, columns or plain content. This means that > whenever > allowed_as_child_of() of an element is invoked, that method could check > its potential > parent element, and if that does not contribute to the Bootstrap's grid > structure (such as said > accordion, carousel, panel, etc.) it can go up a further level in the tree. > > This feature would also make it possible to allow plugins depending on the > siblings context. > > > > Backwards Compatibility > > Since we don't need the complicated caching functionality anymore, I even > believe that it > reduces the amount of code. By adding an overridable method > allowed_as_child_of() to the > base class CMSPluginBase, this feature could even be implemented in a > backward compatible > manner. This method then just would have to examine the plugin's attribute > parent_plugins > and the attribute of its ancestor child_plugins to determine whether it > is allowed of > being added or not. > > > > Implementation > > In case the django-CMS community agrees on this proposal, I will > implement this feature so > that it is available in a future major release. With this in mind, I'd > like to open a discussion > about it. > -- Message URL: https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id Unsubscribe: send a message to django-cms-developers+unsubscr...@googlegroups.com --- You received this message because you are subscribed to the Google Groups "django CMS developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-cms-developers+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/django-cms-developers/3fed5e38-f82f-4c32-a894-4d2732a18280%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
