[Plone-UI] Plip. Placeless adding

Alberto Lopes alberto at alopes.com
Sun Dec 23 11:11:27 UTC 2012

+1 on the "global add" idea, and the location field on the add/edit form,
defaulted to the context.

However, I would not put the "global add" option in the add item menu.

I feel like the edit bar follows a semantic in which everything you click
on it applies to the current context. If the add menu included the global
add option, that semantic would be inconsistent.

Besides, I think it could confuse inexperienced editors, which would see
unrestricted content types on both the "add here" and the "global add" menu.

My suggestion would be to leave the "add item" menu as it is now and to
include the "global add" in the site actions area along with the site setup
and dashboard links.

That way, it is accessible from anywhere in the site and does not break the
edit bar semantics.
Em 23/12/2012 04:42, "Christian Ledermann" <christian.ledermann at gmail.com>

+1 this is a common use case
On Dec 23, 2012 6:47 AM, "Dylan Jay" <djay at pretaweb.com> wrote:

> Hi,
> We came up with this idea over PretaWeb drinks on Friday. Thoughts?
> Anyone interested in seconding?
> Proposer: Dylan jay
> Seconded:
> Motivation
> --------------
> Many times custom types are only designed to be added in a certain
> place, or you may want restrict built in types to limited places in
> your site. In such cases plone is harder work than it should be to add
> a new item. You have know where to add it, browse to that location,
> often with a nav designed for exploring not fast access, then you can
> select from the menu. We've seen installs with lots of place specific
> types where training is needed to teach where to add each type.
> Proposal
> ------------
> Instead, add new menu can be decided into two sections, add here,
> global add.  "Global add" includes any type not in "add here"
> All add forms will have a path/location field. If you click global add
> you can select from available locations using this field (perhaps with
> sensible default). If only one location in site, this will be read
> only. If item addable in current folder then context will be default.
> Some type might need to be excluded from global add like pfg types.
> Adding location field to types makes plone more familiar to users of
> other CMs and also allows a user to change their mind on where it
> should go as they are creating content. It could also be a URL field
> where uses could enter folders that don't exist and they will be
> added. This also allows setting short name.
> Assumptions
> -----------------
> Deliverables
> -----------------
> - New add menu implementation
> - modify standard metadata on standard types so forms include path
> field. Or else use schemaextender. Modify dexterity to do same.
> - widget for path with browse button and editable path.
> - Change the way factory creation works in AT and dexterity to allow
> creation in different folder.
> Risks
> --------
> Add menu could get long. Could be mitigated having a more button or scroll
> list.
> _______________________________________________
> UI mailing list
> UI at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-ui

UI mailing list
UI at lists.plone.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-ui/attachments/20121223/cd656ee5/attachment.html>

More information about the UI mailing list