Что означает общедоступность/публичность папки pulic_html?
Ну, вы уж совсем под дурачка не косите. Сервер автоматом отдает находящиеся в ней файлы.
Все известные мне Web-серверы используют концепт корневого каталога сайта. Про обязательность не скажу, но по традиции принято указывать корневой каталог для каждого создаваемого под Web-сервером сайта, даже если он нафиг не нужен (нет проблемы указать какую-нибудь пустую папку в качестве корня).
Perun пишет:
Почему прикладные папки с картинками, js скриптами работают только изнутри папки public_html, а из того же уровня иерархии папок(если эти папки положить на одном уровне с пабликом) - нет?
Эээ... паблик сопоставляется с адресом /. Как сервер будет автоматом адресовать что-то лежащее вне паблика? Да и /../ - это уже небезопасно. Сервер наоборот с таким должен бороться.
Perun пишет:
В инструкциях некоторых хостеров написано, что нужно помещать файлы проекта в папку паблик. А как же сами файлы проекта с кодом? Или это зависит от политики настроек сервера, что он разрешает- только исполнение, или и чтение/запись?
Уже давно все вменяемые хостеры предоставляют «папку проекта», лежащую на один уровень выше корня ;) У некоторых есть возможность указать любой уровень вложенности и любое имя корня относительно этой «папки проекта» (т.е. любой подкаталог, подподкаталог и т.д.).
Если отдельный сайт создаешь, то соответственно и отдельный блок VirtualHost для него создаешь. Если меняешь местоположение сайта на диске, то соответственно правишь настройки этого сайта. (Добавление)
А в программном коде стараешься вообще не использовать абс. пути в чистом виде. Как определить абс. путь относительно фронта, я показывал на др. форуме. (Добавление)
Что касается конфига, у тебя должен быть отдельно общий конфиг для всех вирт. хостов, например extra/httpd-vhosts.conf, или отдельные конфиги для каждого вирт. хоста. Так вот в контексте вирт. хоста при помощи директивы DocumentRoot нужно прописать полное имя корня сайта, например:
Под Win прямые слеши допустимы. Наверняка в OS все это можно сделать через GUI-панель. Я подобными сборками не пользуюсь, т.к. не хочу загружать мозги лишней хренью. (Добавление)
т.е. избыточной инфой. (Добавление)
1. Я про содержимое показанных actionIndex и actionPage (прежде всего).
2. Так я про роутинг и писал, а не MVC в целом Доступность экшина не должна определяться его физ. присутствием. Кроме того, должна быть возможность привязки к разным адресам одного и того же экшина. (Добавление) LIME
P.S. Проверка существования метода немного лучше, чем проверка существования файла, но в общем та же фигня. Я вам на др. форуме перечислил осн. виды роутинга. (Добавление)
Суть в том, что нужно опираться на адреса или адресные маски, а не на имена контроллеров/методов. При роутинге могут всплывать внутренние технические «адреса» с именами контроллера/метода, но это уже результат перевода внешних адресов.
Pavl, это не роутинг, а полная хрень. Или вы что-то попутали, или автор – идиот.
Получается практически то, о чем я вам писал на др. форуме:
Цитата:
P.S. Конечно, может быть и примитив вроде определения имени файла непосредственно из адреса, например из /page получается имя page.php или page.tpl, потом проверяется существование этого файла и т.д. Но такие вещи даже рассматривать не надо.
(Добавление)
Контроллер походу вообще один на все, поэтому вот это подтверждает мои слова про хрень:
(Добавление)
Про помесь данных с кодом уже молчу. Даже для учебки это отстой. Точнее древность несусветная. (Добавление)
Кстати, самые идиотские уроки больше всего популярны ;) Уроки Попова – это уже давно мем. Русаков (если там именно его авторство) походу не далеко ушел. Возможно, это тот же Попов в новой обертке
Lolya, показанную «защиту» при помощи константы сейчас редко кто использует. Выносите все php-файлы, не являющиеся точками входа, за пределы корня сайта.
А попытка таким образом защититься от неAJAX-запросов сразу показывает полное непонимание вами осн. принципов клиент-серверного взаимодействия. Можно спокойно не защищаться, если нет цели защититься именно от «парсинга ботами». Но если оч. хоЦА, при выполнении запроса отправляете какой-нить специфический заголовок, а в обработчике проверяйте его наличие. Используйте крос-доменную защиту и т.п.
Что верно? Вы не ответили на мой вопрос и не показали, что я просил.
Реализуется, наверно, путем совмещения шаблона и данных из БД.
Шаблон – это не страница. При отсутствии сопутствующих данных обычно выводится совсем другая страница с другим шаблоном. Например, в демке к статье, ссылку на кот. я давал, при запросе по адресу /articles/my-first-article используется один шаблон, потому что в таблице статей существует запись my-first-article, а при запросе по адресу /articles/my-forty-first-article выдается 404-ая страница со своим шаблоном, потому что в таблице статей нет записи my-forty-first-article.
Движок умеет генерировать страницы из шаблонов и данных из БД.
Вопрос в том, что на этих страницах должно быть. Пользователь должен проходить опрос прямо на странице или ему просто должна показываться какая-то инфа на странице? (Добавление)
Сократите множества до неск. элементов и покажите, что должно быть на страницах.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 129
