Closed iturgeon closed 11 years ago
We don't intend to change this either, the keys represent the records PK values.
It's just that they seem numeric if you have a numeric single PK column, but if your related record would have a compound key, you would see alphanumeric keys, which obviously you wouldn't be able to renumber even if you wanted.
So I don't think there's another option that to "mustachify" the array and loosing the PK information.
I get that ORM isn't going to change how it builds those sparse arrays, just wondering if there is any desire to get nested models to work with mustache out of the box?
Maybe theres a good place to do this within the Parser's mustache driver?
Could it be an option to add something like Arr::reindex() ?
I've added Arr::reindex(), that recursively re-indexes a multi-dimensional array, leaving string keys untouched.
Would that help you?
Nice! I think that'll work just fine for this problem. :+1:
Cool. Let me know the results.
Closed due to no feedback.
I just thought I'd bring this up, not sure if it's worth fixing, or where it should be fixed.
The php mustache library is fairly clear about it's opinions in the differences of iterating hashes vs lists: https://github.com/bobthecow/mustache.php/wiki/Mustache-Tags#lists-vs-hashes
This causes a problem when iterating through a list of related models from the Fuel Orm because they are keyed off their indexes. They are evaluated as a hash, not iterable, and do not render as expected.
Example
Mustache library requires that I convert the comments array to a non-sparse indexed array.
\Orm\Model::to_array()
preserves these keys, with no option to remove them.My current fix is to add a method called
Model_Article::to_mustache()
that is a copy of\Orm\Model::to_array()
with one minor change; it doesn't preserve the keys.Ideas? Opinions?