mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-15 19:32:40 +01:00
dcec8e60cc
Summary: Ref T3092. Releeph's objects basically go like this: - At the top level, we have Projects (like "www" or "libphutil") - Each project has Branches (like "LATEST" or "v1.1.3") - Each branch has Requests (like pull requests, e.g. "please merge commit X into branch Y (in project Z)") Currently, there's no real "project detail" or "branch detail" page. Instead, we have a search results page for their contained objects. That is, the "project detail" page shows a list of branches in the project, using ApplicationSearch. This means that operations like "edit" and "deactivate" are one level up, on the respective list pages. Instead, move details onto the detail pages. This gives us more room for actions and information, and simplifies the list views. Basically, these are "detail pages" where the object content is a search interface. We do something simliar to this in Phame right now, although it's messier there (no ApplicationSearch yet). @chad, you might have some ideas here. Roughly, the design question is "How should we present an object's detail view when its content is really a search interface (Phame Blog for Posts, Releeph Project for Branches)?" I think the simple approach I've taken here (see screenshot) gives us reasonable results, but overall it's something we haven't done much or done too much thinking about, I think. Test Plan: {F54774} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T3092 Differential Revision: https://secure.phabricator.com/D6771 |
||
---|---|---|
.. | ||
PhabricatorApplicationSearchController.php | ||
PhabricatorSearchAttachController.php | ||
PhabricatorSearchBaseController.php | ||
PhabricatorSearchController.php | ||
PhabricatorSearchDeleteController.php | ||
PhabricatorSearchEditController.php | ||
PhabricatorSearchHovercardController.php | ||
PhabricatorSearchOrderController.php | ||
PhabricatorSearchSelectController.php |