Just one getChildren method please

Can you believe that with at least three different getChildren type mthods no one does what I want to do? And what I’m looking for is not complicated, I simple want to get all of the children to the current document. I don’t care what the permissions are, published or not, deleted or not, I can deal with that. But I don’t think it can be done through the API.

getAllChildren(): doesn’t really get all children because it leaves out anything a webuser doesn’t have access to
getActiveChildren(): doesn’t get private, unpublished, or deleted docs
getDocumentChildren(): still checks web permissions and will only let you get all published or all unpublished docs, not both

I feel like I’m missing something obvious, maybe I am.

Anyway, I would like to write one method with enough options to be able to handle anything we can throw at it and be able to be backwards compatible with the others so that they can be nothing more than wrappers to the one swiss army knife getChildren method. So, any requests?

Here’s what I’m thinking so far:

• Separate options for getting any combination of, published, deleted, menuhidden, webuser has access, manager user has access
• Get children from multiple parents
• Custom fields
• Sort fields and directions
• Limits
• Depth (for getting grandchildren, great grandchildren, etc)
• Custom SQL WHERE clauses

I’m considering building get TVs into it too but I’m afraid it would be too hard on performance.

Adam:

Already added for 0.9.2 --> see getChildIds($id) and getParentIds($id), as well as the new array $modx->documentMap

[NOTE: oops sorry, I think I misread the post the first time -- this doesn’t address all you want, but is a shortcut to getting all of the child document ID’s upfront without executing a SQL query at all]

-Jason

Seems to me like the way to go about this is to create one mother child grabber... (okay that sounded weird ) that is highly flexible. Perhaps getDocumentChildren would be good for this since it is already pretty flexible. Then have the other API functions merely fill in some of the parameter blanks for you.

The multiple parents thing could be handled by chaning there where clause from

WHERE sc.parent = X
to
WHERE sc.parent IN(<array of ids)>

It would work with ONE id (for backwards compatibility) as well as multiple.

As of right now it doesn’t look like there is an "access" parameter, but seems like that could be added too.

It already allows for custom fields. Sort fields and directions can be done too... with a workaround I’ve used a couple times. Basically if you have multiple sort fields and directions, you put everything but the last sord dir in the $sort parameter:

$sort="field1 ASC, field2 DESC, field3 ASC, field4" $dir="ASC"

Limits are provided for already.

Depth... now that is a trick. Seems like recursion within the snippet using this function would be the way to go here.

Custom where clauses already allowed.

In short
So it seems to me like we’re "almost" there with the current getDocumentChildren API function. A little tweaking of that one and we’d be in business. And again, other get_____Children() functions could simply have some of the parameters built in and then call the getDocumentChildren function.