Re: VIDEO: Simplifying Plone with tiles and shortcodes

On Wed, Mar 26, 2014 at 1:55 AM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:
> That is only 3 more than you currently do.

With Paul's dozens of folders, those extra three clicks are a
coefficient, not an isolated constant.  This is a non-issue if what is
possible from the add-new menu is pre-configured templates to route
around those extra steps (not just a vocabulary of FTI titles) [1].

>> That is just a *lot* of work to create a folder-like page.
>> I fully agree with Sean's comments earlier that some way of quickly
>> generating pre-defined subtypes (one of which I can then call "Folder",
>> thank you very much ;-)  would be a solution.

Something marked as a folder ought to behave differently for DAV/FTP,
so there is some real marking/subtyping necessary, not just view
manipulation?

Also, having only one portal_type can give us extra work to route
around normal workflow arrangements bound to type names.  Selecting a
workflow chain based on some ordered list of interfaces provided
(lookup multi-adapter by type interface, subtype marker) instead of
solely by portal_type might be helpful?

> So if we did have a kind of layout/template idea where clicking Add New > Folder, created a FolderishPage type, preset with a folder listing, would that solve your issues?
> Something similar to this? http://plone.org/products/plonetemplates

Subtyping (for templating/add-menu purposes) could be about any/all of
tiles configured, extra form schema conferred to the edit tab [2],
icons, pre-defined portlet assignments, and marker interfaces (and by
consequence object actions available, workflow definition chain
binding/lookup, maybe other things).

>> I guess what worries me most is that it does not easily translate into
>> filesystems. On more occasions than I care to remember, having an
>> opt-out in the form of Transmogrify, Import/Export, Webdav or even FTP
>> has saved my sorry behind, and a lot of content.
>
> Webdav is a good point.
> One way might be support folder rich content as a .index_html file inside the folder. I think we might need to look at supporting additional field values via a .properties.yaml file anyway because what we have now is a real mess.
>

Agreed, don't think DAV/FTP representation is intractable.  Having
solutions for the "primary field" and properties payloads as you
suggest makes sense.


Sean


[1] There are are always UX risks for changing what shows up the add
menu, if not done right: (a) too many choices, (b) too few choices,
(c) too flat a list, (d) too many submenus, (e) list so large the menu
scrolls off the viewable page area.

[2] This is really the only space I've worked in from a subtyping
standpoint; at a former employer seemingly ages ago, we sponsored
development and were the initial user of Products.ContentFlavors.  The
closest thing I have come up with now for Dexterity types is
https://github.com/seanupton/experimental.flavors -- the problem with
either approach is that marking a content instance with a flavor (or
behavior) after creation is tedious, and this was largest user
complaint I received from deployment of a large media CMS deployment
using the "flavors' concept.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech