Bug #70560
closed
DataProvider exclusivity issues
0%
Description
In a nutshell:
Part of the reasoning behind implementing DataProviders over itemsProcFunc was the exclusive nature of itemsProcFunc: define one and any previously defined itemsProcFunc would be removed. This was solved by allowing any number of DataProviders to be registered, but unforunately this has only moved the exclusivity issue to another place. Now, the exclusiveness is in the fact that only a single DataProvider can apply at any time - in the case of backend_layout, based on a user selection. So, where before any itemsProcFunc would overwrite the one before - now, any selected DataProvider will prevent all others from being consulted. Status Quo.
We need to get around this exclusiveness so that any DataProvider may manipulate the items list without necessarily having been selected.
See https://github.com/FluidTYPO3/flux/issues/940 for a thorough background.
Suggested strategy:
1. Extend the DataProvider pattern with one additional method: trigger() which accepts the same $parameters array as the processing function.
2. Implement this method in the base DataProvider and make it return TRUE if the default parameter matches the current expectation (e.g. if name of DataProvider is currently selected as backend_layout).
3. Process items returned by any DataProvider that has returned TRUE from trigger(). Always process all DataProviders.
This will finally losen up the DataProvider pattern enough that they are truly inclusive in nature.
Updated by Christian Kuhn over 8 years ago
don't get it. are you talking about formEngine data providers and form related itemsProcFunc here?
Updated by Frans Saris over 8 years ago
If I understand Claus correctly he is talking about the BackendLayoutDataProvider here. But I do not understand the exclusive issue here. When you register multiple BackendLayoutDataProvider's all of them are consulted to add there items to the $backendLayoutCollection.
Or are you talking about DataProviders in general and is the BackendLayoutDataProvider a bad example?
Updated by Claus Due over 8 years ago
Please read the linked in-depth explanation. It contains a complete description of the exact use case; reading it answers both of your questions guys. It's most evident from the way BackendLayoutDataProviders work but I'd have to assume it's an issue anywhere. AFAIK yes, your DataProvider gets added to the DataProviderCollection, but the resolveDataProvider returns ONE instance that is then asked for whatever the DataProvider provides (be_layout setup, items for selector, whatever).
Updated by Stefan Neufeind almost 8 years ago
Since we stumbled across that problem as well (using flux/fluidcontent together with backend-layouts) in 7 LTS I hope to maybe add a bit to the discussion.
The problem was that when adding child-content, that content needed to end up in the "randomly chosen" colPos=18181 which represents the magic number for the fluidcontent-column. (Until we might maybe find a better solution for that anyway.) Since the backend-layout didn't have that column TYPO3 also wasn't able to resolve the list of allowed content-elements (CType). So you couldn't (cleanly) save the new element.
If I understand Claus' explanation correctly it's currently not (easily?) possible to add the magic column-number internally while the backend-layout doesn't contain it.
As a workaround you can of course add a column to the backend-layout with that number and use backend-CSS to hide that column :-) (Dirty, but proven to work.)
Updated by Claus Due almost 8 years ago
It seems the symptoms of this problem are made worse by FormEngine completely rejecting or removing such "invalid values" even if they are added to the items selector, if the items are added using custom methods (which these are). See also https://forge.typo3.org/issues/76509 which narrows down the problem - I think both need to be solved to allow that integration to work.
Updated by Susanne Moog about 4 years ago
- Status changed from New to Needs Feedback
As I don't know flux and the methods mentioned here seem to have changed in between the versions, I'm having a hard time trying to understand what the issue is and how to reproduce it. Can you provide a simple core test case, that shows the problem?
Updated by Christian Kuhn about 2 years ago
- Status changed from Needs Feedback to Closed
Hey. I hope it's ok to close here for now: The issue is stalled an quite a bit changed codewise meanwhile. Let's start with a fresh issue if this is still a problem.