Open mindeffects opened 11 years ago
mindeffects
commented
11 years ago mindeffects submitted:
I came across this "problem" when I tried to create a menu with Zurb's Foundation. In order to make those flyouts (submenus) work you have to use "&parentClass" which only will be successful if "is_folder" is set. Took me a while to figure out what caused the problem.
openconcept
commented
11 years ago openconcept submitted:
I think the whole concept of having to mark a document a container is flawed.
If an element has sub-elements (children), it is a container. If not, it's not a container. The fact that you can drag and drop any document as a child of another document, whether or not it has been marked as a container, supports this.
I can see why the "is_folder" flag could simplify some SQL queries, but this seems to be ignored by core but needlessly respected by some packages like Wayfinder.
Maybe we could just get rid of the "manually-marking-as-container" concept? Alternatively, for compatibility, assume that any document is by default a container? I. e. is_folder flag always on.
gadamiak
commented
11 years ago gadamiak submitted:
The @is_folder@ being set has a side effect of container suffix being applied, which is @/@ by default. This is not what I'd expect for resources not being real folders but what would happen with @is_folder@ being on by default.
openconcept
commented
11 years ago openconcept submitted:
Then I think the obvious solution is that any create, delete or move operation involving a document with parent should set the parent's flag on completion. That also means unsetting the flag if the last child has been moved or deleted. Will involve both source and target parent in case of a move operation.
mindeffects
commented
11 years ago mindeffects submitted:
Since the "is_folder" is also connected to the FURL functions, at least a visual sign would be a "nice to have", like a "folder icon with an excamation mark".
I had situations where I needed a resource with page-URL because this resource showed a summury of is childeren: a team page, where each member had his own resource but the team was displayed on one "all together" page. A forced "is_folder" would have made this impossible.
I would love to see a more flexible aproach here, with a system setting for "default behavior" like "auto set", "ask" and "I don't care, you do your job yourself".
gadamiak
commented
11 years ago gadamiak submitted:
mindeffects wrote:
I had situations where I needed a resource with page-URL because this resource showed a summury of is childeren: a team page, where each member had his own resource but the team was displayed on one "all together" page. A forced "is_folder" would have made this impossible.
The same for me: I happen to use parent resources with @is_folder@ unset when children are not to be available by URL.
rygar
commented
11 years ago rygar submitted:
maybe there should be separate (and hidden) variable, that will tell if 'is_folder' has been set/unset manually?
if 'is_folder' will be set/unset automatically (based on children's presence) there is no point in exposing it in document in the first place (because user will not have control over it anyway)
mindeffects created Redmine issue ID 9401
After working with the "parent"-option of Wayfinder I noticed that these evaluate the flag "is_folder" (aka "container") to check if a resource is a parent. But this flag has to be set manualy – drag&drop is not enough. The resource tree, on the other hand, does not care if "is_folder" is set or not, it just finds one or more children and marks a resource as a folder. And then you are doomed: one cannot distinguish if a folder is a "real" container (with the flag set) or just a faux container. So all folders have to be checked. On an active system this check might be neccesary quite often. And it's a super-nagging job!
All these possibilities would help to deal with this "is_folder" thing and keep friendly URLs working.
Or Wayfinder could learn not to rely on the flag, like the tree does.
cheers Oliver