<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On 23/12/2012, at 10:11 PM, Alberto Lopes <<a href="mailto:alberto@alopes.com">alberto@alopes.com</a>> wrote:<br>
<br></div><blockquote type="cite"><div><p dir="ltr">+1 on the "global add" idea, and the location field on the add/edit form, defaulted to the context.</p>
<p dir="ltr">However, I would not put the "global add" option in the add item menu.</p>
<p dir="ltr">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.</p></div></blockquote>
<div>Thats a good point.</div><div>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 it. </div>
<div><br></div><br><blockquote type="cite"><div>
<p dir="ltr">Besides, I think it could confuse inexperienced editors, which would see unrestricted content types on both the "add here" and the "global add" menu.</p></div></blockquote><div>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. </div>
<br><blockquote type="cite"><div>
<p dir="ltr">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.</p>
<p dir="ltr">That way, it is accessible from anywhere in the site and does not break the edit bar semantics.</p>
<div class="gmail_quote">Em 23/12/2012 04:42, "Christian Ledermann" <<a href="mailto:christian.ledermann@gmail.com" target="_blank">christian.ledermann@gmail.com</a>> escreveu:<br type="attribution"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>+1 this is a common use case</p><div>
<div class="gmail_quote">On Dec 23, 2012 6:47 AM, "Dylan Jay" <<a href="mailto:djay@pretaweb.com" target="_blank">djay@pretaweb.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
We came up with this idea over PretaWeb drinks on Friday. Thoughts?<br>
Anyone interested in seconding?<br>
<br>
Proposer: Dylan jay<br>
Seconded:<br>
<br>
Motivation<br>
--------------<br>
<br>
Many times custom types are only designed to be added in a certain<br>
place, or you may want restrict built in types to limited places in<br>
your site. In such cases plone is harder work than it should be to add<br>
a new item. You have know where to add it, browse to that location,<br>
often with a nav designed for exploring not fast access, then you can<br>
select from the menu. We've seen installs with lots of place specific<br>
types where training is needed to teach where to add each type.<br>
<br>
Proposal<br>
------------<br>
Instead, add new menu can be decided into two sections, add here,<br>
global add. "Global add" includes any type not in "add here"<br>
All add forms will have a path/location field. If you click global add<br>
you can select from available locations using this field (perhaps with<br>
sensible default). If only one location in site, this will be read<br>
only. If item addable in current folder then context will be default.<br>
Some type might need to be excluded from global add like pfg types.<br>
Adding location field to types makes plone more familiar to users of<br>
other CMs and also allows a user to change their mind on where it<br>
should go as they are creating content. It could also be a URL field<br>
where uses could enter folders that don't exist and they will be<br>
added. This also allows setting short name.<br>
<br>
Assumptions<br>
-----------------<br>
<br>
<br>
Deliverables<br>
-----------------<br>
- New add menu implementation<br>
- modify standard metadata on standard types so forms include path<br>
field. Or else use schemaextender. Modify dexterity to do same.<br>
- widget for path with browse button and editable path.<br>
- Change the way factory creation works in AT and dexterity to allow<br>
creation in different folder.<br>
<br>
Risks<br>
--------<br>
Add menu could get long. Could be mitigated having a more button or scroll list.<br>
_______________________________________________<br>
UI mailing list<br>
<a href="mailto:UI@lists.plone.org" target="_blank">UI@lists.plone.org</a><br>
<a href="https://lists.plone.org/mailman/listinfo/plone-ui" target="_blank">https://lists.plone.org/mailman/listinfo/plone-ui</a><br>
</blockquote></div>
</div><br>_______________________________________________<br>
UI mailing list<br>
<a href="mailto:UI@lists.plone.org" target="_blank">UI@lists.plone.org</a><br>
<a href="https://lists.plone.org/mailman/listinfo/plone-ui" target="_blank">https://lists.plone.org/mailman/listinfo/plone-ui</a><br>
<br></blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>UI mailing list</span><br><span><a href="mailto:UI@lists.plone.org">UI@lists.plone.org</a></span><br><span><a href="https://lists.plone.org/mailman/listinfo/plone-ui">https://lists.plone.org/mailman/listinfo/plone-ui</a></span><br>
</div></blockquote></body></html>