如何解决“非结构化”问题？ PHP 中的导航？
我有一个基于 PHP 的大型 CMS 来管理网页。 所有项目都以树结构组织。 当我编辑项目时，“后退”按钮通常指向其父项目。 因此，通常的工作流程是在树中导航。
现在，时不时地需要一个可以“跳转”到其他项目而不考虑结构的工作流程。
例如，当用户编辑网页时，他们可能想要打开页面附加的模板（完全不同分支中的另一个项目），在那里进行更改，然后单击“保存”时期望返回到他们正在编辑的页面。
目前，我使用
domain.com/admin/template/edit?from=/frontpage/edit
“from”变量确定“保存”和“取消”按钮的目标 URL 来解决这个问题。
当路径变得太长且太复杂时，这种方法会起作用。例如，如果用户
- 编辑页面
- 时打开附加模板
- 并在前端视图中预览该模板
- ，然后希望无缝返回到他们正在编辑的页面，该怎么办？
现在，“历史记录”在最后一项结束，因此当用户从前端视图返回时，原始页面的链接会丢失，他们必须手动搜索。
另一个可能很快发生的问题是，包含所有“来自”值的 GET URL 变得太长，或者完全混乱：（
domain.com/admin/template/edit?from=/frontpage/edit&from=/somepage/edit
&from=/template/preview&/from=template/edit&/from=template_preview ...
你明白了）
我过去通过打开单独的窗口优雅地解决了这个问题，但我真的很想实现通用的无缝单窗口工作流程，主要是因为多个窗口往往会让用户感到困惑。
您如何解决这个问题？
您是否实现了强大的“非结构化”导航，可以在打开多个窗口的情况下正常工作（=一个用户使用不同的导航路径执行多个不同的操作）？
在用户界面方面如何解决这个问题？
我能想到的最好方法是传递一个指向数据库或会话中临时记录的“from”值。该记录包含有关当前路径的所有信息，因此始终可以提供正确的“返回页面 x”值。
我最想听到的是那些成功实施这一点的人的经验，以及他们是如何做到的。
I have a large, PHP-based CMS that manages web pages.
All items are organized in a tree structure.
When I edit an item, the "back" button usually points to its parent item.
So, the usual workflow is navigating through the tree.
Now every now and then, the need arises for a workflow that "jumps" to other items without regard for the structure.
For example, when a user is editing a web page, they may want to open the template the page is attached to (another item in a completely different branch), make a change there, and when clicking "save" expect to come back to the page they were editing.
At the moment, I solve this using
domain.com/admin/template/edit?from=/frontpage/edit
where the "from" variable determines the target URLs of the "save" and "cancel" buttons.
This works up to a certain point when the path becomes too long and complex. For example, what if the user
- edits a page
- opens the attached template
- previews that template in the front-end view
- and then expects to be seamlessly taken back to the page they were editing?
Right now, the "history" ends at the last item so that when the user returns from the front-end view, the link to the original page is lost, and they have to search it by hand.
Another problem that can happen quickly is that the GET URL containing all the "from" values becomes too long, or totally chaotic:
domain.com/admin/template/edit?from=/frontpage/edit&from=/somepage/edit
&from=/template/preview&/from=template/edit&/from=template_preview ...
(you get the drift)
I have solved this elegantly by opening separate windows in the past, but I really want to implement a seamless one-window workflow that works universally, mainly because multiple windows tend to confuse users.
How do you solve this?
Have you implemented a robust "unstructured" navigation that works well with multiple windows open (=one user doing multiple different things with different navigation paths)?
How do you go about this on the user interface side?
The best approach I can think of is passing on a "from" value that points to a temporary record in a database or session. That record contains all the information about the current path, and can thus always provide the right "back to page x" value.
What I would like to hear most is experiences from people who have successfully implemented this, and how they did it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
只是一些建议
预览问题：在 IFRAME 中预览，这样历史记录就不会丢失？
混乱的 URL 问题：如果每个页面都有某种键，除了 URL 路径之外，
您可以将它们在 PATH_INFO 中串在一起，如下所示：
Just a couple suggestions
Preview Problem: preview in an IFRAME, so the history doean't get lost?
Cluttered URL problem: If you have some sort of key for each page, other than the URL path
you could string them together in the PATH_INFO like so:
当用户点击时，您可以为会话构建一堆已访问的页面，每次打开时都会推送一个新页面，当他们单击返回时会弹出。将其存储为会话变量。
诀窍是始终检查他们的引荐来源网址字符串，因为他们也可能使用浏览器的后退和前进按钮。如果他们的引荐来源网址字符串不在堆栈顶部，则您必须扫描堆栈以查看他们是否手动备份到上一页。
You could build a stack of visited pages for the session as the user clicks around, pushing on a new page each time the open it, popping off when they click back. Store it as a session variable.
The trick then is to always check their referrer string, since they may also use their browser's back and forward buttons. If their referrer string isn't at the top of their stack, you'll have to scan the stack for it to see if they manually backed up to a previous page.
只要您只需要后退一次，为什么不在生成要跳转到的页面时传递您想要的任何回链接页面 ID？
As long as you're only needing to backstep once, why not pass in whatever linkback page IDs you want whenever you produce the page you're jumping to?