DataProcessing

DataProcessing is the recommended way to render a Grid Element's children. See Rendering Architecture for how it fits alongside the deprecated legacy TypoScript path; this page is about using it.

GridElementsTeam\Gridelements\DataProcessing\GridChildrenProcessor is a standard TYPO3 DataProcessorInterface implementation. Add it to a content object's dataProcessing array like any other processor, and it fetches the current container's children, the tt_content records related to it through tx_gridelements_container (see Data Model), resolves their FlexForm and backend layout data as configured, and hands the result to Fluid as a plain variable. What that variable looks like, a flat list or a rows/columns matrix grouped by the container's own grid layout, is controlled by its options, see Reference. How to configure and use those options, and the Fluid partials that consume the result, is covered in How To.

Grid Elements ships a ready-to-use static TypoScript template, Gridelements w/DataProcessing, that wires up GridChildrenProcessor on a FLUIDTEMPLATE for tt_content.gridelements_pi1:

tt_content.gridelements_pi1 =< lib.contentElement
tt_content.gridelements_pi1 {
    templateName = GridElement
    templateName.override.field = tx_gridelements_backend_layout
    templateRootPaths {
        1 = EXT:gridelements/Resources/Private/Templates/
    }

    partialRootPaths {
        1 = EXT:gridelements/Resources/Private/Partials/
    }

    dataProcessing {
        10 = GridElementsTeam\Gridelements\DataProcessing\GridChildrenProcessor
        10 {
            default {
                as = children
                # Default options of the grid children processor
                # Change them according to the needs of your layout
                # See the Reference page for the full option list
                # options {
                #    sortingDirection = ASC
                #    sortingField = sorting
                #    recursive = 0
                #    resolveFlexFormData = 1
                #    resolveChildFlexFormData = 1
                #    resolveBackendLayout = 1
                #    respectColumns = 1
                #    respectRows = 1
                #}
            }
        }
    }
}

lib.tt_content.shortcut.pages = COA
lib.tt_content.shortcut.pages {
    5 = LOAD_REGISTER
    5 {
        tt_content_shortcut_recursive.field = recursive
    }

    10 = USER
    10 {
        userFunc = GridElementsTeam\Gridelements\Plugin\Gridelements->user_getTreeList
    }

    20 = CONTENT
    20 {
        table = tt_content
        select {
            pidInList.data = register:pidInList
            selectFields.dataWrap = *,FIND_IN_SET(pid,{register:pidInList}) AS gridelements_shortcut_page_order_by
            where = colPos >= 0
            languageField = sys_language_uid
            orderBy = gridelements_shortcut_page_order_by,colPos,sorting
        }
    }

    30 = RESTORE_REGISTER
}

tt_content.shortcut.variables.shortcuts {
    tables := addToList(pages)
    conf.pages < lib.tt_content.shortcut.pages
}

This is a normal FLUIDTEMPLATE setup with template, layout and partial root paths; GridChildrenProcessor fetches the children, and anything else added to this setup follows regular TypoScript syntax, including other data processors run alongside it. The commented block shows the available options with their default values, see Reference for what each one does. Use the f:debug view helper in a template to inspect what a given configuration actually produces:

<f:debug>{_all}</f:debug>

Every option and internal key is also passed through stdWrap, so values can be assigned dynamically rather than only as TypoScript constants.

For how this processor's option model compares to EXT:container's own ContainerProcessor, including which option configuration approximates its behavior, see Grid Elements and EXT:container.