Как вы структурируете контент вашего сайта? - PullRequest
2 голосов
/ 27 февраля 2009

Стараетесь ли вы сохранить простоту и иметь корневую папку, а затем 1 папку для изображений, javascript, flash и т. Д.? Как вы обычно называете свои папки? Вы даете свои соглашения об именах файлов?

Ответы [ 6 ]

5 голосов
/ 27 февраля 2009

не стандартным способом ... но из моего опыта я придумаю такую ​​структуру:

root/
 -> images/
      -> <subfolder>
      -> upload
 -> js/
 -> css/
 -> data/
 -> docs/
 -> download/
 -> mme/
 -> subpages/
 -> temp/
 -> siteadmin/

root: all 1st level file located there
images: all images. if images for subfolder, then another level there with the same name.  upload is for uploaded images.
js: javascript
css: css
data: some raw data if needed
docs: word doc or pdf for download
download: something that for ppl to downlaod...
mme: other multimedia files. e.g. flash, movie.. soudn clips.etc.
subpages: 2 or subsequent level pages. organized in different folders
temp: any testing page store there.  private, not public.
siteadmin: if you have an admin site. 
3 голосов
/ 27 февраля 2009

Я держу это простым, но тогда моему веб-сайту не нужны вещи, которые вызывают сложность. Как правило, каждая веб-страница имеет имя, соответствующее папке на диске, и эта папка содержит все элементы, необходимые для отображения этой страницы. Иерархия веб-сайта соответствует иерархии на диске.

2 голосов
/ 27 февраля 2009

Если изображений много, тогда папка для них полезна, однако у меня, как правило, 1 файл JS, 1 или 2 CSS.

Самая полезная вещь, которую я считаю, это mod_rewrite всех страниц, как это делает stackoverflow.

2 голосов
/ 27 февраля 2009

Это зависит от проекта, но я обычно использую js /, img / и fl /. Иногда я делю root на код / ​​и контент /, но думаю, что это может быть излишним. Что касается соглашения об именах, мои изображения обычно сопровождаются названием страницы, на которую они обычно встроены. Если они есть на каждой странице, я использую что-то вроде global_ или all_. Я надеюсь, что это помогает ...

1 голос
/ 01 марта 2009
root
+-+ include
  +-- cache
  +-- script
  +-- css
  +-- images

Этот каталог, конечно, не доступен извне.

Почему все включено? Потому что ни один из этих медиа-файлов не обслуживается напрямую. Все они проходят через сценарий, который:

  • Сжатие всех файлов CSS в один файл;
  • Сжимает весь Javascript в один уменьшенный файл;
  • Записывает эти версии в каталог кэша;
  • метки времени css, js и файлы изображений и устанавливает заголовок expires в далеком будущем;
  • Сохраняет кэшированные копии сжатых файлов js и css в каталоге кэша; и
  • Все ссылки на эти файлы проходят через функцию автоматической версии, которая использует время последнего изменения, чтобы изменить URL-адрес, чтобы контролировать, когда клиент получает новую копию (например, /css/screen.1234567890.css), аналогично тому, что делает SO со строкой запроса для таких файлов.

Вышеуказанное может значительно ускорить работу сайта.

Остальная часть структуры каталогов будет отражать структуру меню сайта. Если есть пункты меню верхнего уровня «Заказы» с подменю, то можно поспорить, что вы найдете каталог учетных записей в корневом каталоге.

Все это делает сайт очень и очень предсказуемым, если кому-то еще нужно прийти и поддерживать его. Чрезвычайно важно, чтобы кто-то еще мог найти дорогу.

1 голос
/ 27 февраля 2009

Это действительно зависит от того, сколько страниц на вашем сайте. Вначале может показаться хорошей идеей просто удалить все страницы в корне. Позже, когда у вас будет 120 несвязанных файлов, вы можете начать пинать себя.

Я склонен собирать простую иерархию с 1 глубиной, разбитую по площади сайта. / форумы, / фотографии, / учетная запись и т. д. По опыту я узнал, что количество страниц будет расти намного выше, чем вы ожидали. И я узнал из опыта, что это просто отстой, чтобы переместить страницы из корня в разумную структуру, когда у них есть внешние ссылки. Лучше всего делать это с самого начала.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...