Project

General

Profile

Actions

Feature #51641

closed

Improvement ideas for FlexForm

Added by Gabriel Kaufmann / Typoworx NewMedia almost 11 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Could have
Assignee:
-
Category:
-
Target version:
Start date:
2013-09-02
Due date:
% Done:

0%

Estimated time:
PHP Version:
5.3
Tags:
Complexity:
nightmare
Sprint Focus:

Description

Out of the practice we have some ideas & suggestions that could improve flexforms.

Tag: <Include>EXT:FILE:foobar/xml/myFlexPart.xml</Include>

Usage: Include external flexform parts that are used mutliple times (f.e. similar field configs)

Attribute "scope": optional xpath to define the starting-point of inclusion

Tag: <Group>

Usage: Similar to "Sheet", but in this case to cascade multiple fields into one block.
It could be interesting to use displayCond on a block of fields or to allow additional display-styling attributes on how to order the fields (vertical/horizontal) and may be some more useful.

I would be interested in some feedback and may also help implementing this, if there is enough positive feedback/suggestions on this ideas.

Actions #1

Updated by Mathias Schreiber over 9 years ago

  • Target version set to 7.4 (Backend)
  • Complexity set to nightmare
Actions #2

Updated by Susanne Moog almost 9 years ago

  • Target version changed from 7.4 (Backend) to 7.5
Actions #3

Updated by Benni Mack over 8 years ago

  • Target version changed from 7.5 to 8 LTS
Actions #4

Updated by Christian Kuhn over 7 years ago

  • Status changed from New to Closed

Mmmh, quite frankly, I'd rather stay away from adding more features to the data structure syntax. There are still too many clumsy edges in this area and the parsing is complex. For instance, display conditions are still broken in combination with flex form sections and this is really hard to solve ... we may only be able to do that if we finally change sections to an ajax call.

Additionally, I think we should rather clean up the XML of data structures and flex data before (and find a way on how to cleanly migrate), before we add features in this area. For instance, I think we should kick those "TCEforms" sub arrays in DS, and we may kick the lDEF and vDEF things from flex. This could help to make the whole rendering stuff easier.

For now, I'll close this issue as "won't have this time", there is just still too much mess around before we should think about adding new stuff, imho.

BTW: It is possible to extract single sheets to own files with FILE:EXT:... syntax in DS, so that's possible on sheet level, but not on element level at the moment, see the unit test parseDataStructureByIdentifierResolvesExtReferenceForSingleSheetsWithFilePrefix() as an example for that.

Actions

Also available in: Atom PDF