MODX Staff
I would say they need to be modified to not do that because that was never the intended purpose of this data. It just made sense to sync this data based on absence or presence of children.
I could be wrong, but I believe there are snippets using isFolder to determine if a resource has children. If so, they depend on it being set automatically.
That seems like reasonable standard behavior to me. And if not, we can change this behavior easily.
At present in Revo, "create document here" checks the container checkbox automatically. Deleting the document doesn’t uncheck it, however. but moving the child to another parent does.
Understood, but my preference is not to add more density to the user interface for this, and simply to clarify the distinction in tooltips for the Container checkbox.
The reason I suggested the addition of an automatic "hasChildren" checkbox was to help users understand that hasChildren and isFolder are independent concepts (assuming that we’re going that way).
MODX Staff
There already is a checkChildren() function in the API; modResource->checkChildren() which is used to "Resolve isfolder for the resource based on if it has children." But it’s definitely not faster than using $modx->getChildIds(), as it involves a query to determine if there are children, while getChildIds() uses the data created by the cache engine. You can also retrieve the immediate children via modResource::getMany(’Children’) or use $modx->getCount(’modResource’, array(’parent’ => $resource->get(’id’))) which would tell you exactly how many children there were.
Fair enough. What about adding a hasChildren() method to the API? I think it would be justifiable if isFolder can’t tell you if there are children, it would keep everyone from having to roll their own, and it would make it easier to convert any snippets that currently use isFolder when they should be using hasChildren. I think it would be faster than using getChildIds().
The icon should change, but the children should not disappear. This is simply a mistake in converting the logic from Evo; it should be using isfolder to change the icon and using the absence or presence of children to determine if the node is expandable.
BTW, in Evo, you can’t uncheck the container checkbox if there’s a child (more precisely, you can uncheck it but it doesn’t stick), which is probably good.
In Revo, though, you can uncheck it and save. It changes the icon and the children disappear from the tree (they come back if you re-check it and save). So it looks like the Revo UI is using isFolder to determine if there are children (maybe Evo too). I rest my case about the confusion.
Yes, but checkChildren() doesn’t return anything (and has side effects the user may not know about or want) and many users will be hard put to come up with one of the other choices. I’m suggesting a hasChildren() method that returns true or false using the fastest method. I still think it would be extremely useful if isFolder won’t serve that purpose and its existence will help people understand the two separate concepts.
There already is a checkChildren() function in the API; modResource->checkChildren() which is used to "Resolve isfolder for the resource based on if it has children." But it’s definitely not faster than using $modx->getChildIds(), as it involves a query to determine if there are children, while getChildIds() uses the data created by the cache engine. You can also retrieve the immediate children via modResource::getMany(’Children’) or use $modx->getCount(’modResource’, array(’parent’ => $resource->get(’id’))) which would tell you exactly how many children there were.
The icon should change, but the children should not disappear. This is simply a mistake in converting the logic from Evo; it should be using isfolder to change the icon and using the absence or presence of children to determine if the node is expandable.
MODX Staff
MODX Staff
NO NO NO NO NO!!!!! Please re-read my explanation!
So, if I’m reading the consensus right, manually toggling the Container flag shouldn’t really be done. The presence of having children should determine this, and I suspect that’s how more than 99% of MODx users both use it and expect MODx to behave. I agree.
NO! The toggle needs to remain. There is a difference between isfolder (i.e. the Container checkbox) and the presence/absence of children!
As such, I’d like to remove the checkbox from the admin UI only, and rely on appropriate Manager logic to toggle the flag. If someone still needs a "faux container" they can simply add an unpublished, non-searchable document as a child and solve the requirement without affecting the vast majority of the users. And more importantly, we get a simpler UI while maintaining 100% of the functionality and 99.9% of the flexibility as a result.
NO! The toggle needs to remain. There is a difference between isfolder (i.e. the Container checkbox) and the presence/absence of children!
MODX Staff
I’m not arguing that hasChildren() wouldn’t be a useful convenience method to add, but you can easily determine this now using either $modx->getChildIds($parentId) or via $modx->getCount(’modResource’, array(’parent’ => $parentId)) -- and you can add additional query expressions using getCount() to be more specific (i.e. ’published’ => true, ’deleted’ => false, etc.). Regardless, my point is that there is a difference now in Revo, despite Evo blurring the line since it has no effect on URL structure in the older code.
More ammunition for my point.
isFolder() = checkbox
hasChildren() = has actual children
I’m not arguing that hasChildren() wouldn’t be a useful convenience method to add, but you can easily determine this now using either $modx->getChildIds($parentId) or via $modx->getCount(’modResource’, array(’parent’ => $parentId)) -- and you can add additional query expressions using getCount() to be more specific (i.e. ’published’ => true, ’deleted’ => false, etc.). Regardless, my point is that there is a difference now in Revo, despite Evo blurring the line since it has no effect on URL structure in the older code.
.