[Plone-UI] Plip. Placeless adding

Dylan Jay djay at pretaweb.com
Sun Dec 23 20:29:37 UTC 2012

On 23/12/2012, at 10:11 PM, Alberto Lopes <alberto at alopes.com> wrote:

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

Thats a good point.
Keep in mind we are almost certainly switching to a cmsui toolbar layout
soon. In that layout add new is up on the toolbar with personal tools and
site actions. The green bar contextual distinction isn't as strong in this
case and for that reason I think the add menu is the most logical place for

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

I didn't make it clear but both lists would be restricted. Add here remains
unchanged. Global add will only show types a user can add "somewhere" in
the site, and is not already in "add here" list.

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

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

More information about the UI mailing list