Лучший способ определить URL вашего веб-приложения - PullRequest
Новая
       14

Лучший способ определить URL вашего веб-приложения

3 голосов
/ 10 августа 2009

Я всегда обнаруживал, что определение URL-адресов для других «страниц» в веб-приложении кажется неуклюжим, хрупким или раздутым.

например. у вас есть приложение, которое управляет клиентами, продажами, потенциальными клиентами и, следовательно, имеет следующие «страницы».

  • CustomerList
  • viewcustomer
  • editcustomer
  • addcustomer
  • viewcontact
  • editcontact
  • addcontact
  • проспект (x3? X4?)
  • продажи (х?)
  • продукт (x?)
  • запрос (х?)
  • прогноз (х?)
  • и т.д.. ...

По мере роста приложения число страниц быстро увеличивается до списка из 100+ URL-адресов.

Логика говорит, что просто копировать / вставлять эти URL-адреса там, где это необходимо на странице, уродливо и неудобно, но загрузка 100+ ключей / значений кажется излишней, если вам нужно только 2 или 3 из них на «этой» странице .

Технически это не зависит от языка (ASP, JSP, PHP, RoR, Python и т. Д.), Но я намерен реализовать его на PHP (в настройке MVC). Однако, если у ASP.Net или Rails есть «действительно крутой» способ сделать это, я весь в ушах.

Обновление:

Я на полпути к преобразованию PHP-приложения, не относящегося к MVC, для использования структуры MVC. Ранее у меня был большой набор ключевых ссылок, которые были базовым URL для страницы, например ::1010 

$URLs['CUSTOMER_ORDER_CONTACTS'] = '/customerordercontacts.php';
$URLs['CUSTOMER_PRODUCTS_EDIT'] = '/editcustomerproducts.php';
//etc.

Поскольку я мог ссылаться на экран «Редактирование продуктов клиента» из любой точки мира, каждая страница загружала этот список, так что если / когда URL-адрес изменился на другую страницу ... изменение элемента в списке обновит все ссылки.

Однако, когда я читаю ответы здесь, я думаю, что мог бы случайно ответить на свой вопрос. То, что написал @Blixt, в значительной степени является структурой, которую я / планирую следовать ... в этот момент URL действительно структурирован таким образом, что я не нужно иметь этот список вообще :

Пример. Если я выполняю рендеринг клиента ... и хочу предоставить ссылку на каждый контакт 

//pseudo code
$contacts = $customer.getContacts();

//previous rendering list of links
foreach($contacts as $key => $value){
  echo('<a href="'.$URLs['CUSTOMER_CONTACT_VIEW'].'?customer='.$custID.'&contact='.$key.'">'.$value.'</a>');
}

//new rendering list of links
foreach($contacts as $key => $value){
  echo('<a href="/customer/'.$custID.'/contact/'.$key.'">'.$value.'</a>');
}

Ответы [ 4 ]

1 голос
/ 10 августа 2009

Мне нравится сохранять URL-адреса как можно более логичными и избегать URL-адресов, специфичных для фреймворка (учтите, что в будущем вы можете изменить фреймворк, который затем должен будет продолжать использовать ваши старые шаблоны URL-адресов, чтобы избежать разрыва внешних ссылок.)

В основном: 

# All customers:
/customers/
# New customer:
/customers/new
/customers/?new # another version if you don't think "new" deserves its own path
# Existing customer:
/customers/123/
/customers/123 # another version if you want the concept that it's a page, not a
               # directory
# Edit customer:
/customers/123/edit
/customers/123?edit

# Some sub-list for a customer:
/customers/123/orders/

# and so on...

Если честно, я лично предпочитаю второй пример в тех случаях, когда я привел два примера. Он использует концепцию файловых систем, согласно которой списки являются «каталогами», а отдельные записи - «файлами». Каждый путь представляет некоторый тип данных, а другие пути разделяются с помощью строки запроса (/customers/?new).

После того, как вы определились со своими структурами URL, вы должны посмотреть, как реализовать это в вашей веб-среде. Большинство фреймворков, которые я считаю «хорошими», имеют некоторую поддержку отображения URL-адресов (обычно с некоторыми шаблонами, поддерживающими подстановочные знаки, такие как регулярные выражения). Таким образом, ваши шаблоны могут выглядеть следующим образом, используя мои вторые примеры (регулярное выражение): 

^/customers/$ -> CustomerList
^/customers/(\d+)$ -> Customer # This will check the query string for "edit" etc
                               # to determine which mode to use.
^/customers/(\d+)/orders/$ -> OrderList
0 голосов
/ 10 августа 2009

Структура URL должна учитывать поисковую оптимизацию. Даже если сайт работает только внутри организации, он, вероятно, сканируется внутренним механизмом или будет в будущем. Вот несколько ключевых моментов из двух ресурсов Google, которые я считаю полезными:

Рекомендации по структуре URL

от http://www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf:

Использовать слова в URL - URL со словами, которые имеют отношение к вашему сайту содержание и структура дружелюбнее для посетителей, переходящих на ваш сайт. Посетители помнят их лучше и может быть более охотно ссылаться на них.

Укажите одну версию URL для доступа к документу - Чтобы запретить пользователям от ссылки на одну версию URL и другие ссылки на другие версия (это может расколоть репутация этого контента между URL), сосредоточиться на использовании и обращении к один URL в структуре и внутренний связывание ваших страниц.

Структура URL

от http://www.google.com/support/webmasters/bin/answer.py?answer=76329:

Структура URL сайта должна быть максимально простой. Рассмотрим организовать свой контент так, чтобы URL построены логически и в манера, которая наиболее понятна люди (когда это возможно, читаемые слова вместо длинных идентификационных номеров).

Рассмотрите возможность использования знаков препинания в своих URL. URL http://www.example.com/green-dress.html гораздо полезнее для нас, чем http://www.example.com/greendress.html. Мы рекомендуем использовать дефисы (-) вместо подчеркивания (_) в вашем URL-адрес.

Слишком сложные URL, особенно те, которые содержат несколько параметров, может вызвать проблемы у сканеров создавая излишне большое количество URL, которые указывают на идентичные или похожий контент на вашем сайте. Как результат, робот Google может потреблять много больше пропускной способности, чем необходимо, или может быть не в состоянии полностью проиндексировать все содержание на вашем сайте.

0 голосов
/ 10 августа 2009

in PHP Я пойду для простой настройки, как это:

www.example.com/application/controller/action/parameter

где application должен быть каталогом

controller должен быть дочерним каталогом своего родителя application

action должен быть методом в контроллере (по умолчанию) OR может быть другим подкаталогом в application->controller->action, потому что иногда мне нужно разделять методы и реальные файлы.

тогда параметр может быть передан действительным приложениям действительным контроллерам действительное действие

для меня это была самая динамичная установка, которую я могу достичь.

если вам нравятся примеры из реального мира, пожалуйста, спросите меня.

0 голосов
/ 10 августа 2009

В CodeIgniter (PHP) они отображают URL-адреса на объекты и их методы, т.е. 

/customers/list/3

будет звонить Customers->list('3'). Вы достаточно гибки, чтобы переписать это поведение по мере необходимости для отдельных URL-адресов. На мой взгляд, это очень хороший способ.

Django (Python) позволяет, нет, заставляет вас делать это вручную. Хотя эта попытка дает вам максимально возможную гибкость, сопоставляя URL-адреса с помощью регулярных выражений для функций, она становится действительно сложной для больших приложений.

Возможно, эти методы помогут.

Приветствия

...