FieldtypeRepeaterMatrix: ProcessPageEdit times out when used recursively

[ghost]

I'm trying to use FieldtypeRepeaterMatrix in a recursive setup leading ProcessPageEdit to run indefinitely. The problem seems to be the following:

InputfieldRepeaterMatrix::renderReady preloads all inputfields used in the matrix and one of them happens to be the very same field which in turn preloads all it's fields which leads to an infinite loop.

Is there any way to resolve the problem other than using a different field for every level of recursion?

ProcessWire Version is 3.0.15 FieldtypeRepeaterMatrix Version is: 0.0.3

[ryancramerdesign]

Repeaters can be nested, but the same exact repeater field can't be nested within itself without creating an infinite loop.

[ghost]

Hi,

sorry for the late reply. I ended up using two repeater fields - one for the first level and one for the second level of recursion.

Is there any way to build structure like the bootstrap grid with repeater matrices? That is: Have rows with multiple columns but also allow columns to have rows in them as well?

Thanks

[CaelanStewart]

@ryancramerdesign - just had this issue.

It is possible to get recursive Fieldsets/Repeaters like described here.

I built a fieldset system that does it for a piece of software I'm working on in work. It has Fieldsets, Repeaters, and Repeater Matrixes (I used your name for it, it's a cool name).

Basically, you should only be instantiating to the depth specified by the form data on page creation and form instantiation.

Fieldsets are different, because when instantiated, it immediate creates its child fields. But, for Repeaters, that are empty upon initial creation, that isn't the case, because there are no instances of a repeater item (really just one of a set of Fieldsets) to instantiate to then cause the same recursively.

If you are recursively iterating on the structure of the field definitions themselves for some reason, then you will get these infinite loops unless you keep track of all objects already iterated to avoid continually iterating over circular references.

But, if the underlying architecture is right, there's no reason why you can't get this to work.

It would be great to see recursive Repeaters/RepeaterMatrix fields here, since it is incredibly useful for block-based layouts, being able to then have a repeater matrix type which displays itself in a column based layout, which can then be done to arbitrary depth (where appropriate). It just seems wrong to be duplicating and individually maintaining two separate fieldsets.

If the underlying architecture can't support this due to legacy code, maybe this is something that is done in a 4.0 release, a re-structure of certain fundamental ProcessWire constructs.

(also perhaps renaming Pageimage to PageImage and Pagefile to PageFile, etc., pretty please 😛)

This screenshot gives a good idea as to how I structured it. Here also the fieldset system is used to define the form that is used for defining other fieldsets.