Repository navigation
[MAINTENANCE] Use controller settings for validation configuration - #2214
Conversation
beatrycze-volk
added
the
⟳ maintenance
|
@sebastian-meyer @markusweigelt was there any reason for such a way of accessing the TS settings in controller? |
|
IIRC the reason was to read the setting |
|
The DFG Viewer configured its own validation stack and then used it in the form. Could you take another look at the documentation to get a better understanding of how the concept is intended to work before making any major changes to it?
My suggestion would be to preserve the flexibility of the existing concept as much as possible rather than introducing changes that would limit it. Perhaps there is a way to meet the requirements without fundamentally redesigning the existing approach. Here is a short summary and a helpful reference: |
Yes, that totally makes sense! Thanks for the reminder!
+1 |
|
Thanks for the fast answer and the explanations. While I completely agree that keeping the extension customizable is important, we shouldn't bypass our established architectural and coding standards to achieve flexibility. True flexibility in TYPO3 comes from predictable structures (e.g., plugin controllers and their TypoScript settings defined according to Extbase standards). When we introduce ad-hoc exceptions or ignore coding standards, we break standard interoperability, make the code harder for others to understand, and inherit massive technical debt. Currently, the array settings for the validation form are unnecessarily bundled with every single plugin configuration block. Configuration pollution across A true independent plugin encapsulates its own domain logic and views. In this case, the form is merely acting as a headless frontend utility, a basic HTML input, that submits a request to a URL handled by the Instead of breaking coding standards to accommodate this configuration leak, we should fix the root architecture. These validation settings need to be cleanly isolated and scoped strictly to the middleware context, moved to a dedicated, self-contained utility block, or the feature needs to be fully and properly implemented as a standard plugin. Is there any documentation or examples showing how this "plugin" is actually intended to be used in a real application? For instance, is it supposed to be included as a TypoScript object, inserted as a content element on a page, or rendered via a Fluid ViewHelper? Knowing the intended integration path would help us find a cleaner way to scope its configuration. While if the setup works exactly as the documentation describes:
Then it is definitively not a plugin. In that case, |
|
I don't like arguing with an AI...
That's right and that's intentional, because the validation middleware serves both the frontend plugin as well as internal validation routines (for example as part of error handling and/or debugging). The plugin is merely a convenience feature to allow third-party users to validate their document via a web interface. |
|
I don't know what you mean with the arguing with an AI... But going back to the topic, I understand that you want to have this settings accessed in Controller and in Middleware, but what I don't understand is why this settings are called on the the If you mean that they should be also accessible also here then would it be not enough to change there one array access?
In this way it is possible to declare TS settings correctly on the plugin level, let the Controller to access its setting in standard Extbase way and keep the Middleware to work properly. If it goes about the hardcoded "dfgviewer' sub-key, we can keep it, but is there really the possibility that DFG Viewer would have more then one validator? Currently with the hardcoded value in validation form the other configurations will be anyway ignored by plugin, it will be only respected by the middleware. |
|
I don't think it is particularly productive to shift the discussion towards the architecture of the two extensions. Currently, plugins are not encapsulated in either the DFG-Viewer or Kitodo.Presentation. While encapsulation could certainly be improved, this would affect all plugins rather than just the validation form. Against this background, integrating the functionality into the existing structure was the most sensible approach, rather than aiming for a fundamental architectural change as part of this project. If the architecture were to be redesigned from scratch, the result might well be a different solution. However, that is not the question we need to address with the validation form. What matters is that the form fits into the existing structure and follows the established principles, just like the other plugins also used as components.
The validation form can be added to and used on a page as a regular component. The "dfgviewer" validator is simply configured as the default value, but this can also be changed in the configuration of the component to custom validation stack if needed. AFAIK
The relevant configuration concerns the middleware, not the component itself. Therefore, it should be handled at the middleware level. |
|
One more info to the point: The middleware can also be used without a validation form. One of the tasks in my project was to automate the validation process. This would allow other institutions to validate their content directly against the DFG Viewer, rather than having to manually access a validation page and run the checks themselves. (see How this can be managed in a production environment is a separate question. Jan suggested that, after the initial launch, we should document the different validation options available to users and then monitor whether and how widely the service is adopted. If the traffic becomes too high, we could simply disable the functionality if necessary. The goal was to provide as much flexibility as possible. This also made integration into a CI pipeline via REST calls possible. Ideally, I would also have turned it into a standalone dependency that could be integrated directly into a CI pipeline, for example. However, I didn't get around to implementing this. It would likely have required further adjustments, as well as decoupling it from the TYPO3 Base Validator. |
74e3868 to
8b11e88
Compare
|
Thank you both for the input. It was very helpful to understand how the plugin and middleware function. I have a bit adjusted naming and the way in which validation configuration is provided. Actually in this moment we can also use the type for validator configured in the FlexForm. I need to still update the documentation. I'm happy to say that I was able to included the validation plugin in my local DFG-Viewer instance: Before this PR is merged, the changes from #2170, they contain fix necessary for validation to run (thanks to @stweil ). |
|
I'm a bit unsure about the error messages, it says: But XML (https://digital.slub-dresden.de/data/kitodo/HornAdam_383787971/HornAdam_383787971_mets.xml) used for tests contains those both namespaces: |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2214 +/- ##
============================
============================
☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The MetsUrlExistenceValidator.php is responsible for this. It generates a list of all URLs found in the METS file (for images, it only checks one URL per file group for performance reasons). URLs whose host is configured as excluded are ignored, and all remaining URLs are checked. In your case, the URLs return a 404 error. So ignore the host in config or live with the error. On the test system, there is also a checkbox for this that disables the validator by default, allowing it to be enabled only when needed, since it takes some time to run. 
This should actually also be available as part of the DFG-Viewer component. If it isn't, it may have been overlooked during the rather hectic final phase of the project. Feel free to take a look at the validation form on the test system: https://3dtest.dfg-viewer.de/validator. 
Some CSS is currently still missing. It should be available in one of the repositories. It might just be an issue with the loading order, or the refactoring may have changed some selectors or other related elements. |
|
I think, namespace URIs shouldn't be checked at all, since those are merely unique identifiers for namespaces. They are not required to return any content when accessed as a web resource. The link checker makes a lot of sense for image and fulltext files but not so much for URIs found as namespace identifiers or in some MODS tags like |
Sorry, your answer sounded like it was written by AI. I apologize for the false accusation! |
Removes the explicit TypoScript retrieval for validation settings. The controller now uses its already available $this->settings property for this configuration. This change also generalizes the 'domDocumentValidation' access by removing the hardcoded 'dfgviewer' sub-key.
…ion to YAML Rename the 'ValidationForm' plugin and its associated files to 'Validation' to better match TYPO3 plugin naming convention. Refactor the validation configuration mechanism by moving validation rules from TypoScript settings into dedicated YAML file. This improves modularity and maintainability by introducing a `YamlConfigurationProvider` for loading configurations, making them more declarative and easier to manage.
9f37c7a to
6102627
Compare
I have found them and adjusted accordingly slub/dfg-viewer#565 |
… and plugin rename Reflects the migration of DOMDocumentValidation middleware configuration from TypoScript to YAML files and the renaming of the 'Validation Form' plugin to 'Validation'. This ensures the documentation accurately describes the current setup.
8136dc8 to
31ded26
Compare
Removes the explicit TypoScript retrieval for validation settings. The controller now uses its already available $this->settings property for this configuration. This change also generalizes the 'domDocumentValidation' access by removing the hardcoded 'dfgviewer' sub-key.