Some arrays may contain key/item combinations that are associative to the application using the array, but also items that can have any key they want, such as hook_views_data()'s return value (From a documentation point of view, the 'table' key is associative and all others are not, although from an application point of view they are).
To be able to describe such arrays using blueprints, we need one array blueprint that can handle associative and non-associative items.
The attached patch adds XtoolsBlueprintArrayAssociative's behavior to XtoolsBlueprintArray.
To do: remove XtoolsBlueprintArrayAssociative and convert all XtoolsBlueprintArray and XtoolsBlueprintArrayAssociative occurences to the new XtoolsBlueprintArray format.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | xtools_1658072_01.patch | 35.75 KB | xano |
| #1 | xtools_1658072_00.patch | 3.14 KB | xano |
Comments
Comment #1
xanoComment #2
xanoFor consistency we might want both XtoolsBlueprintObject and XtoolsBlueprintArray to only accept XtoolsChildElement objects, which are changed to accept a child name (array key/object property) as well. Objects and arrays can then be defined the same way, and there will be no difference between associative and non-associative array items anymore, except the presence or absence of an array key.
Comment #3
xanoThe consistency was nice, but made blueprint definitions very hard to read.
Comment #4
xanoComment #6
xano