2009-11-25 31 views
5

Tôi có một CMS lớn dựa trên PHP để quản lý các trang web. Tất cả các mục được sắp xếp theo cấu trúc cây. Khi tôi chỉnh sửa một mục, nút "quay lại" thường trỏ đến mục cha của nó. Vì vậy, quy trình làm việc thông thường đang điều hướng qua cây.Làm cách nào để bạn giải quyết điều hướng "không có cấu trúc" trong PHP?

Bây giờ mọi lúc và bây giờ, nhu cầu phát sinh cho luồng công việc "nhảy" đến các mục khác mà không quan tâm đến cấu trúc. Ví dụ: khi người dùng đang chỉnh sửa trang web, họ có thể muốn mở mẫu trang được đính kèm (một mục khác trong một nhánh hoàn toàn khác), thực hiện thay đổi ở đó và khi nhấp vào "lưu" mong đợi để quay lại trang họ đang chỉnh sửa.

Tại thời điểm này, tôi giải quyết việc này bằng

domain.com/admin/template/edit?from=/frontpage/edit 

nơi "từ" biến xác định các URL mục tiêu của các nút "save" và "hủy".

Điều này hoạt động đến một thời điểm nhất định khi đường dẫn trở nên quá dài và phức tạp. Ví dụ, nếu người dùng

  • chỉnh sửa một trang
  • mở mẫu kèm theo
  • xem trước rằng template trong giao diện front-end
  • và sau đó hy vọng sẽ được thực hiện trơn tru trở lại trang họ đang chỉnh sửa?

Ngay bây giờ, "lịch sử" kết thúc ở mục cuối cùng để khi người dùng trở về từ giao diện người dùng, liên kết đến trang gốc bị mất và họ phải tìm kiếm bằng tay.

Một vấn đề khác có thể xảy ra một cách nhanh chóng là địa chỉ URL GET chứa tất cả các "từ" giá trị trở nên quá dài, hoặc hoàn toàn hỗn loạn:

domain.com/admin/template/edit?from=/frontpage/edit&from=/somepage/edit 
&from=/template/preview&/from=template/edit&/from=template_preview ... 

(bạn nhận được sự trôi dạt)

tôi đã giải quyết điều này một cách tao nhã bằng cách mở các cửa sổ riêng biệt trong quá khứ, nhưng tôi thực sự muốn triển khai luồng công việc một cửa liền mạch hoạt động phổ biến, chủ yếu là do nhiều cửa sổ có xu hướng gây nhầm lẫn cho người dùng.

Làm thế nào để bạn giải quyết vấn đề này?

Bạn đã triển khai điều hướng "không có cấu trúc" mạnh mẽ hoạt động tốt với nhiều cửa sổ đang mở (= một người dùng đang làm nhiều việc khác nhau với các đường dẫn điều hướng khác nhau)?

Bạn làm cách nào để thực hiện điều này ở phía giao diện người dùng?

Cách tiếp cận tốt nhất mà tôi có thể nghĩ là chuyển giá trị "từ" trỏ đến bản ghi tạm thời trong cơ sở dữ liệu hoặc phiên. Bản ghi đó chứa tất cả thông tin về đường dẫn hiện tại và do đó luôn có thể cung cấp giá trị "quay lại trang x" phù hợp.

Điều tôi muốn nghe nhất là trải nghiệm từ những người đã triển khai thành công việc này và cách họ đã làm điều đó.

+0

Bạn có thể xem các CMS lớn như Drupal, Wordpress và Joomla đã giải quyết vấn đề này như thế nào. Họ có thể đã thực hiện một số nghiên cứu về điều này và (hy vọng) đã đưa ra quyết định tốt. –

+0

Có lẽ bạn có thể thử nén biến GET của mình? – jkndrkn

Trả lời

2

Chỉ cần một vài đề xuất

Xem trước vấn đề: xem trước trong một IFRAME, vì vậy lịch sử sẽ không bị mất?

vấn đề URL lộn xộn: Nếu bạn có một số loại chìa khóa cho mỗi trang, khác với đường dẫn URL

(i.e. /frontpage/edit = 952, 
/frontpage/edit&from=/somepage/edit = 763, 
/template/preview = 651, 
template/edit = 612, 
template_preview = 866 etc.) 

bạn có thể chuỗi chúng lại với nhau trong PATH_INFO như vậy:

domain.com/admin/template/edit/952/763/651/612/866 
+0

Ý tưởng đường dẫn rất tốt. Tôi nghĩ rằng tôi sẽ đi với điều đó. –

0

Miễn là bạn chỉ cần quay lại một lần, tại sao không chuyển bất kỳ ID trang liên kết nào bạn muốn bất cứ khi nào bạn tạo trang bạn đang nhảy tới?

+0

Có thể/sẽ có nhiều bước lùi và đặt toàn bộ chuỗi thành các biến GET nhanh chóng vượt quá 1024 byte cho phép. –

2

Bạn có thể tạo một chồng các trang được truy cập cho phiên khi người dùng nhấp chuột xung quanh, đẩy vào một trang mới mỗi khi mở nó, bật ra khi họ nhấp lại. Lưu nó dưới dạng biến phiên.

Bí quyết là luôn kiểm tra chuỗi liên kết giới thiệu của họ vì họ cũng có thể sử dụng các nút quay lại và tiến trình của trình duyệt của họ. Nếu chuỗi liên kết giới thiệu của họ không nằm ở đầu ngăn xếp của họ, bạn sẽ phải quét ngăn xếp để xem liệu họ có được sao lưu thủ công lên trang trước hay không.

Các vấn đề liên quan