What does the Container checkbox actually do?

I think I will vote on the "lose it" side unless I hear another argument. My problem is that at present, there’s no stable definition of "container," or, more precisely, there are two separate definitions.

1). A resource with it’s container field set.
2). A resource with children.

The cleanest way to resolve them into a single definition is to use #2 (I’m almost sure that’s what Wayfinder and Ditto do). If unchecking the container checkbox changes the tree, then the tree and Wayfinder are using different definitions of "container." That’s not good.

It’s also confusing that a container, unlike a Windows (& Mac?) folder, can also be a perfectly normal document so I would lean toward losing the folder icon too and just let the + indicate children.

Well, remove it if it doesn’t screw things up!

Param: parents

Purpose:
IDs of containers for Ditto to retrieve their children to &depth depth

Options:
Any valid MODx document marked as a container

Default:
Current MODx Document

Related:
- <documents>
- <depth>

&filter=`isfolder... ?

It will affect FURLs. Dont remove it.

Wayfinder also makes extensive use of isFolder and there are lots of references to it throughout the code. I’m not sure what that means for the question since it may not a good idea to let the user declare something to not be a container when it really is one.

Quote from: mrhaw at Aug 21, 2009, 07:31 PM

Well, remove it if it doesn’t screw things up!
...
&filter=`isfolder... ?

Sometimes I also use &hideFolders=`1`, hiding particular documents that are conrtainers only conceptually (aggregating different site subtrees).

The presentation of Resources in the tree should ignore the container checkbox (i.e. isfolder column in site_content) and depend entirely on the presence or absence of child Resources (which I believe it does), but FURLs, other internal functionality, and add-ons make extensive use of this important meta-data. It definitely should not be removed or merged with the "has children" definition.

Quote from: OpenGeek at Aug 22, 2009, 02:22 PM

The presentation of Resources in the tree should ignore the container checkbox (i.e. isfolder column in site_content) and depend entirely on the presence or absence of child Resources (which I believe it does), but FURLs, other internal functionality, and add-ons make extensive use of this important meta-data. It definitely should not be removed or merged with the "has children" definition.

The tree display in Revo *does* respond to the checkbox. Checking the box displays the resource using the folder icon and the little expansion arrow whether it has children or not.

That’s why I suggested merging the two definitions and using them consistently. When the current usage confuses the lead core developers, there’s a problem IMHO.

I get the argument that you might want to treat an empty container marked as a container with the checkbox differently in Ditto or Wayfinder. But then maybe we shouldn’t be setting it automatically when children are added or deleted. Maybe we need to leave it to be set only by the user and add another automatically set checkbox called "Has Children;" haschildren could them be a pseudo content field calculated in the modx class but with no field in the DB. Users would then know that they were separate concepts and developers could use the appropriate one.

it is handled automatically, so how about at least hide the checkbox in the manager interface?

Quote from: BobRay at Aug 22, 2009, 03:36 PM

The tree display in Revo *does* respond to the checkbox. Checking the box displays the resource using the folder icon and the little expansion arrow whether it has children or not.

Only in terms of the icon which is displayed, which is correct; visually being able to see if the Resource is being treated as a folder or a file is important IMO, as it affects the URL structure directly (e.g. container/ or container/index.html vs. container.html). This provides flexibility in how your Resources are accessed.

Quote from: BobRay at Aug 22, 2009, 03:36 PM

That’s why I suggested merging the two definitions and using them consistently. When the current usage confuses the lead core developers, there’s a problem IMHO.

I don’t believe we are confused; there are just multiple issues being discussed here. How the manager presents it is as planned, disregarding the automatic setting of the value which is leftover behavior from 0.9.x.

Quote from: BobRay at Aug 22, 2009, 03:36 PM

I get the argument that you might want to treat an empty container marked as a container with the checkbox differently in Ditto or Wayfinder. But then maybe we shouldn’t be setting it automatically when children are added or deleted. Maybe we need to leave it to be set only by the user and add another automatically set checkbox called "Has Children;" haschildren could them be a pseudo content field calculated in the modx class but with no field in the DB. Users would then know that they were separate concepts and developers could use the appropriate one.

Exactly, we shouldn’t be setting it automatically, though I see no reason to introduce a checkbox for hasChildren; that is information that needs to be and can easily be determined in real-time. The presence or absence of the tree expansion icon should be enough visual cue for this. I think a control on the create/edit Resource form for this would be more confusing than understanding the original purpose of the checkbox: to control the way the Resource is accessed and the way it behaves, as a folder (i.e. container), or a file (non-container).

Quote from: OpenGeek at Aug 22, 2009, 07:04 PM

Quote from: BobRay at Aug 22, 2009, 03:36 PM

I get the argument that you might want to treat an empty container marked as a container with the checkbox differently in Ditto or Wayfinder. But then maybe we shouldn’t be setting it automatically when children are added or deleted. Maybe we need to leave it to be set only by the user and add another automatically set checkbox called "Has Children;" haschildren could them be a pseudo content field calculated in the modx class but with no field in the DB. Users would then know that they were separate concepts and developers could use the appropriate one.

Exactly, we shouldn’t be setting it automatically, though I see no reason to introduce a checkbox for hasChildren; that is information that needs to be and can easily be determined in real-time. The presence or absence of the tree expansion icon should be enough visual cue for this. I think a control on the create/edit Resource form for this would be more confusing than understanding the original purpose of the checkbox: to control the way the Resource is accessed and the way it behaves, as a folder (i.e. container), or a file (non-container).

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.

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.

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).