MidCOM 2.5 Datamanager Rewrite Requirements
This is a MidCOM 2.5 Development Technical Note covering the Datamanger Rewrite. Everything written here is subject to change without notice.
Important note: API compatibility is not a goal of this rewrite. You will have to adapt your components to match the new Datamanger, and even schema compatibility will be done through some kind of special importer, new schemas will be more complex then the old ones.
Edit loop handling
Generally, the edit loop should be decoupled from the actual storage objects, so that a user can stay in the edit loop as long as he likes without actually touching the original content object:
Storage object usage
The storage object should no longer be touched unless all prerequisites for saving are actually met. Areas where this is important are:
- Attachment upload: No more need for save / edit / save / edit looping, instead have an "upload now" button directly in the Blob/Image widgets.
- Validation: Don't write an object unless the content is validated.
- Creation: Temporary objects should be created outside the regular content tree, so that unsubmitted creation forms no longer can produce ghost objects. Cleanup of those obejcts is done by a Datamanager Cron Job.
"Infinite" Editing
The currently enforced way of ending editing as soon as the user clicks cancel must no longer apply. Instead, we need an extensible sets of operations, that a form submit can trigger. Each must keep the actual form content stable and reload the form afterwards, for example after image uploading.
In addition, there need to be "shortcuts" for AJAX to do its magic, for example, having a POST target which just lists the filtered contents of a dropdown. This would only be a query, where the change of the actual form data is not immediately changed on the server. Instead, the client form is updated and sent to the server at a later time.
Finally, those shortcuts should be able to handle the so-called "in place editing", again an AJAX thing. In those cases an DM driven view is shown, which uses AJAX to dynamically change pieces of the view into a mini-form for the double-clicked field for example. When the user submits it, the field updates on the server, and JS is used to change it on the client.
Multi-Page editing
The ability to divide an editing process into several pages (like the all-famous "Wizards") should be built into the core, having multiple schemas apply to the same object at once. Of course, all rules above have to apply.
DM Event Loop
The Event Loop must be rewritten so that it is easier usable by the client. As always, all loops link back to the URL where the form was originally handled.
DM handling should now be done in a more object oriented fashion. A class (which can be subclassed obviously) takes all the content handling. The general division of processing and rendering must of course stay stable. But the default implementation should include most of the run-of-the-mill processing the current Datamanger puts into the components.
Important points:
- Relocation links for saving / cancellation
- Various callbacks for subclassing (saving, cancelling, creating)
The central handling class should rely only on callbacks overwritten in subclasses, while there should be a default implementation working roughly like the original Datamanger by calling back into the main handler.
Other considerations
The 'attachment' data storage target will be dropped in favor of the longtext parameters.
AJAX Support (Milestone 2)
The Datamanager must be able to support a wide range of AJAX operations on the long run. The request processing must be as extensible as possibel therefore.