Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Blueprints/StreamlineDataHandling

From TYPO3Wiki
Jump to: navigation, search

<- Back to blueprints overview

Blueprint: Streamline Data Handling

Proposal Streamline the data handling to move away from a separated backend/frontend handling
Owner/Starter Soren Malling
Participants/Members -
Status Draft, Discussion, Voting Phase, Accepted, Declined, Withdrawn
Current Progress Unknown, Started, Good Progress, Bad Progress, Stalled, Review Needed
Topic for Gerrit ###gerrit_topic###

Target Versions/Milestones

  • The concept came to my mind, while working on a project running 7 LTS

Goals / Motivation

Introduce a streamlines handling of data handling, so no matter what context (FE/BE) the same actiones are processed (versioning, workspace, hooks/actions etc)

Concept

We know the concept of hooks today and we know the DataHandler. As a editor, this is really awesome, as we can introduce all sort of fancy actions at certain actions. The frontend users (imagine a community, visitors publishing news etc) does not have the same actions applied to there actions, unless it's implemented in the (kind of duplicated) code in the frontend plugin.

The concept here, is to use hook in ex. the DatabaseConnection API and make it possible to have tasks/actions being applied to a certain action. Example:

If a visitor creates a user, and they need to confirm there account by a link in a email, it's coded inside the frontend plugin (or service) If a backend user creates a fe_user, the same actions can be triggered, if they both used the same "service" layer for DataHandling.

Implementation Details

Kind of similar to a message queue, introduce a interface, where these actions are coded up against. The actions are managed in a backend module, where the context can be set (sys_language_uid, in workspace, in frontend/backend etc)

A first version/PoC can be implemented as a standalone extension and could easily live like that

Risks

Being more awesome and streamlined

Issues and reviews

Dependencies upon other Blueprints

Kind of depending/working "against" the DataHandlerFrontend blueprint:

Blueprints/DataHandlerFrontend

External links for clarification of technologies