Products.cmfplone: TTW Dexterity types in Plone 5.[0|1] folderish by default and no option to change to non-folderish

[zopyx]

A content-type created TTW in Plone 5.0a3 is folderish by default and there is no way to make a non-folderish content-type.

[thet]

/cc @pbauer

[jensens]

I think this is by intend. I would like to get rid of the idea of contentish and folderish anyway. If everything's a container by default it would simplify a lot. And if one doesn't want to have items in the container it's a question of addable types configuration in FTI.

[vangheem]

Agreed. Let's stop making the distinction between folderish and non-folderish. Make everything a folder and sometimes you don't want to be able to add things to certain types.

[zopyx]

Again, being able to make a content-type folderish easily through a
behavior is a nice feature. But having basic types like images and files
folderish by default does not make sense - neither from the integrators
point of view nor from the user experience expectations of the user.

2015-02-09 2:55 GMT+01:00 Nathan Van Gheem [email protected]:

Agreed. Let's stop making the distinction between folderish and
non-folderish. Make everything a folder and sometimes you don't want to be
able to add things to certain types.

—
Reply to this email directly or view it on GitHub
https://github.com/plone/Products.CMFPlone/issues/317#issuecomment-73447099
.

[tisto]

I'm a bit confused. This has been discussed in the FWT and we postponed the discussion to Plone 5.1. If TTW types are folderish by default right now we have to revert it.

cc @pbauer?

[jensens]

IIRC @pbauer reverted this/ did not merge this? /me is confused too

[vangheem]

I have confirmed--still no way TTW to create a non-folderish content type TTW.

[zopyx]

Appears like a blocker for the Plone 5.0 release, right?

[pbauer]

This is intended and no Issue. The situation is as follows:

1. Custom types created TTW are always folderish since the feature to add itemish content was removed in 2013 (see https://github.com/plone/plone.app.dexterity/commit/fde6ed5a08aaa2645d1a5fe5149b8622168918ca). By default they cannot contain any content which makes them behave exactly as items. If you find any case with folderish content where no content can be added to behave different from itemish content, please create tickets. I fixed some cases but there may be others.
2. The default content-types provided by plone.app.contenttypes are still non-folderish in Plone 5. There is PLIP https://dev.plone.org/ticket/20144 but that has been postponed to 5.1 by the FWT. For Developers there are three ways to make them folderish: https://github.com/collective/collective.folderishtypes, https://github.com/plone/plone.app.contenttypes/pull/195 which is similar to collective.folderishtypes but converts all types (think a stored preview to a website inside a Link) and https://github.com/plone/plone.app.contenttypes/pull/196 which also has migrations from non-folderish to folderish.

[zopyx]

Intended? This is major usability foul.
I vote to reopen this issue ans mark it as blocker,
Folderish behavior is nonsense.
Being unable to remove this behavior is major bug.
Closing this issue counts as developer ignorance for me.

Am 18.08.2015 um 23:16 schrieb Philip Bauer [email protected]:

This is intended and no Issue. The situation is as follows:

Custom types created TTW are always folderish since the feature to add itemish content was removed in 2013 (see plone/plone.app.dexterity@fde6ed5). By default they cannot contain any content which makes them behave exactly as items. If you find a case where folderish content where no content can be added to behaves different from itemish content. Please create tickets if you do. I fixed some cases but there may be others.

The default content-types provided by plone.app.contenttypes are still non-folderish in Plone 5. There is PLIP https://dev.plone.org/ticket/20144 but that has been postponed to 5.1 by the FWT. For Developers there are three ways to make them folderish: https://github.com/collective/collective.folderishtypes, plone/plone.app.contenttypes#195 which is similar to collective.folderishtypes but converts all types (think a stored preview to a website inside a Link) and plone/plone.app.contenttypes#196 which also has migrations from non-folderish to folderish.

—
Reply to this email directly or view it on GitHub.

[pbauer]

@zopyx can you please name your reasons why you think the current behavior is not optimal? I explained that from the user-perspective the behavior for plone.dexterity.content.Container when no content can be added to it is exactly the same as with content using plone.dexterity.content.Item. There is also no huge perfomance impact as explained in https://dev.plone.org/ticket/20144. Please explain the reasons why you think a decision that was based on user-testing and was discussed on many occasions by many people is developer ignorance.

[zopyx]

Not optimal? Because it is against the standard user expectations. If you create a documents in Word or Excel and save then it is folderish on Mac or Windows? Why should it be different in Plone?

Creating a File-ish content-type TTW...why should it be folderish? What would be the semantics of the folder_contents for a folderish File content-type? This is all weird and confusing for users and adds extra complexity to the UI and the user. A folderish behavior must be optional as stated multiple times.

I am not in the position to justify the standard user expectations...the ball is in your field to explain why a default folderish behavior for content types having no semantics about contained content at all is a cool thing. I don't get it...in the end we have to implement an INonFolderish behavior and attach it to default content types in order to suppress folder contents and related functionality e.g. by hiding related actions using CSS...sorry, _broken_by_design_ unless there is a story for having the default behavior. And I don't care about when it was removed...changing the behavior for whatever reason is a major fail.

[tisto]

I agree with @zopyx here. The difference between folderish and non-folderish objects is the first concept you explain to people that are new to Plone (document vs. folder). Whether we like it or not, this is still one of the core principles when working with Plone today. Just because we remove the option for folderish types in one place does not mean we simplify anything in my opinion. Inconsistency just confuses people.

If we want to move to folderish types we have to do it right and everywhere, or not at all. What we are doing here is the worst of all options in my opinion.

[pbauer]

As I said the UI for content where no content can be added should not differ in any way from the behavior of itemish content. No folder_contents, no add-menu, no default_page etc. pp. I did not check if all this is already correctly implemented and I guess it has not, so it would be cool if you added issues for anything you find. I also think folderish files and images can make sense in some cases (e.g. if you want to store files converted to other formats).

Also, the FWT could discuss reverting https://github.com/plone/plone.app.dexterity/commit/fde6ed5a08aaa2645d1a5fe5149b8622168918ca to re-add the option to create itemish content ttw. I would not mind a lot but basically I agree with @davisagli that the option confuses people.

[davisagli]

Yes, you should be able to pick whether your type acts as a folder or not, but that should be done by editing the list of types that may be contained inside (some containable types = folder, no containable types = non-folder) rather than by changing the class used for instances of the type. We decided at one of the Emerald sprints to only create TTW types using the Container class, because admins who created types using Item were getting stuck when they added some instances and then realized they really wanted a container. The intent was not to make it impossible to have non-folderish items, but to change the definition of what makes an item folderish so that it's easier to switch between the two. Anywhere in Plone code that is deciding something is a folder based on its class is buggy and needs to be updated to do it with this logic: an item is a folder if a) it already contains items or b) its factory type info allows adding items.

[zopyx]

I am not getting the point and can not understand how one can make such a design decision that
Is obvious counter-intuitive.

Anyway...there must be at least an easy optional way to hide/disable folder related options from the related views.

I pointed the problems out. This change is breaking basic user expectations.

How would TTW types treated by a 4.3 to 5.0 migration? Item-ish types would suddenly after a migration turned into folders?

Am 20.08.2015 um 16:19 schrieb David Glick [email protected]:

Yes, you should be able to pick whether your type acts as a folder or not, but that should be done by editing the list of types that may be contained inside (some containable types = folder, no containable types = non-folder) rather than by changing the class used for instances of the type. We decided at one of the Emerald sprints to only create TTW types using the Container class, because admins who created types using Item were getting stuck when they added some instances and then realized they really wanted a container. The intent was not to make it impossible to have non-folderish items, but to change the definition of what makes an item folderish so that it's easier to switch between the two. Anywhere in Plone code that is deciding something is a folder based on its class is buggy and needs to be updated to do it with this logic: an item is a folder if a) it already contains items or b) its factory type info allows adding items.

—
Reply to this email directly or view it on GitHub.

[davilima6]

From what I understand they won't be folders until you explicitly enable adding items on them, however they will inherit from dexterity.content.Container so future upgrade is easier. Moreover, dexterity.content.Item would vanish with time -- or become a way to ensure the content-type must not be "turned" TTW.

[zopyx]

The behavior is bad...my project "XML Director" provides some an additional
"XML Text" field.

So I created a new CT TTW with one additional field of type "XML Text".

Adding a new items of the new CT shows the edit screen, I can save and see
the default view of the type...fine so far.

Within the folder contents view of the Plone root I click on the object and
then it shows up with the folder_contents view of the new CT...this is odd
behavior because my CT is not supposed to be folderish...instead it should
just show the default view rendering all fields of the type.

In addition: the folder_contents view of the CT does not show any option to
add new content objects to the folder - there is no option neither in the
Plone toolbar nor within the folder_contents view itself.

See the problems?

I can provide a screencast if necessary.

Tested with a decent coredev buildout as of today

• Plone 5.0b4.dev0 (5007)
• CMF 2.2.8
• Zope 2.13.22
• Python 2.7.8 (default, Oct 13 2014, 12:40:26) [GCC 4.4.7 20120313 (Red
  Hat 4.4.7-4)]
• PIL 2.7.0 (Pillow)

I
2015-08-21 4:23 GMT+02:00 Davi Lima [email protected]:

From what I understand they won't be folders until you explicitly enable
adding items on them but they will inherit from
dexterity.content.Container. Moreover, dexterity.content.Item will vanish
with time -- or become a way to ensure the content-type must not be
"turned" TTW.

—
Reply to this email directly or view it on GitHub
https://github.com/plone/Products.CMFPlone/issues/317#issuecomment-133248039
.

[davisagli]

Okay, that indeed sounds like a bug with the new folder contents...it should get fixed so it doesn't let you navigate into an item unless it is folderish by the definition I gave above (i.e. if its FTI allows some contained types)

[tkimnguyen]

Coming from https://community.plone.org/t/new-dexterity-content-type-works-like-a-folder/3274/5 I have to agree that the user experience at this point is confusing...for me. I have caught myself wondering why a TTW CT I created shows the contents view. We are nearing 5.1 so it would be really nice to have that logic @davisagli suggests.

[jensens]

Looks like Somebody should implement it, but ... (see The Story of Everybody, Somebody, Anybody and Nobody, credits to @gforcada who brought this up at the conference...).

Probably a bounty would help?

[jensens]

note: this is still an issue.