One data manager to rule them all?

I seem to find my self creating tables and forms all over again when creating Flow apps. So I was thinking about if it was possible to create

One data manager to rule them all #fireworks

The ideas is inspired by the $TCA array from TYPO3, where we are able to configure a table, with fields and a visual listing and editing interface.

I would like to hear, if other are facing the same issue, have already solved it and can point to a repository.

First draft of Settings.yaml

This is just an idea, of how it could be approached

Flowpack:
	Manager:
      actions:
        'edit':
          icon: 'icon.png'
        'delete':
          icon: 'delete.png'
        'new':
          icon: 'new.png'
    entities:
      'customers':
        provider:
          options:
            entityClassName: 'Vendor\Package\Domain\Model\Entity'
        pagination:
          resultsPerPage: 10
        filters:
          'onlyConverted':
            conditions:
              - 'object.state = 10'

Other things on my mind

Providers

Data could come from all kind of providers, not nescessarily a entity with a repository from the Flow application. F.eks. “PodioProvider” with data from a Podio.com workspace, and similar

This will require a proper interface with the different CRUD commands covered.

Hooks & events

Hooks and events is important, to interact with more system. For ex., when a specific type is deleted, remove from a search index

Validation

Validation both from annotations in a object and if a external provider return error

Using Neos.Form for… well, forms :slight_smile:

It’s obvious to use Neos.Form for the form part - this could make a great synergy for both projects.

Share your thougt and ideas on this project idea - that would be great

1 Like

Are you aware of the CrudForms package by Sandstorm? It might do exactly what you need :wink:

Thanks for the link - it can certainly tailer some of the needs, so I hope that others also have a look at it :slight_smile:

I’m aware of that, the concern, is the dependency that you bring into your own package by adding annotations to your own package. If you remove Crudforms from your application, you also have a cleanup of your models, or else the reflection will throw exceptions about the annotations.

I don’t see it as solving the issue I started presenting. I would like to think of this as a CMT - Content Management Toolbox - where you can as a integrator, can add entities with very little knowledge.
Just like Fusion has sort of become that easy tool for integrators, to get Neos CMS stuff running with very little knowledge.

Also consider this as a tool that could be integrated in to Neos CMS for managing data. For example the Mailchimp tool you made and other similar listings and managing.