о, крутяк. спс! а впечатления как? =) быстро пашет? между прочим в сниппеты можно параметры передавать кажется даже на несколько строк разбивать.
я сейчас не помню цифирь, но из кеша раз в 5 быстрее точно ) но это опять же все на уровне "нелоуворд" опробывалось )
1. pin.class.php а в чем логика такого роутинга? если я запросил определенный урл, то мне нужен именно он либо ошибка, а получается я получу в результате неизвестно что, вместо сообщения что урл неверный. 2. когда я вижу код типа include 'classes/pincms.class.php'; то ожидаею что будет просто инклюд кода класса. был удивлен обнаружив там внизу еще и вызов PinCMS::Init(); неправильно это както. подгрузка класса это одно, а инициализация это другое. и в другом месте должно быть. 3. богатое наличие приват свойств в классах - говорит о том что делать наследников будет невозможно или геморно. код всегда развивается. где гарантия что завтра не нужно будет сделать класс наследник с более высокой абстракцией. протектед хотябы. 4. файлы разные: cache.class.filecache.php, cache.class.memcache.php - а классы внутри называются одинаково. class Cache ... непорядок. причем в одном из них есть сразу вызов Cache::Init(); а в другом нет. это опять отсыл к вопросу 2 5. неоднократное Код (PHP): if (file_exists($path)) { include $path; } ну а если нет такого файла? может ошибку сгенерить или сообщение вывести ? 6. если напрямик вызвать в браузере postincludes.php и etc ? что увидим 7. preincludes.php: header('Content-Type: text/html; charset='.CFG::$page_codepage); а если я хочу скриптом сгенерить картинку, текст.. да все что угодно кроме html. зачем так связывать руки? 8. ThrowOnTrue() & ThrowOnFalse(). хватило бы и одной. т.е. вместо ThrowOnFalse(file_exists($tag['filename']), 'file not found at ' . $tag['filename']); - ThrowOnTrue(!file_exists($tag['filename']), 'file not found at ' . $tag['filename']); эти вопросы появились сразу при просмотре кода. я пока его так и не запускал) ибо ну нет у меня пхп 5.4. а ставить ради одного скрипта лениво. тем более что я считаю что 5.4 там как собаке левая нога. все тоже самое можно сделать на 5.2 даже
если вы хотите, вы можете обрабатывать всех юзеров и урлы вида /users/15/delete в файле /pages/users.php. Для этого надо увеличить значение CFG::$route_to_parent на нужное число шагов. В текущей реализации эквивалентны адреса со слешем на конце и без. Можно и это отключить установив значение в ноль. Добавлено спустя 1 минуту 11 секунд: не вижу смысла. Данный инит не зависит от других классов. Подключил - можешь работать. Добавлено спустя 33 секунды: Наследников никогда не будет. Никогда. Подробнее можем обсудить в соседней теме. Добавлено спустя 5 минут 18 секунд: А какой смысл их называть по-разному? Использоваться может только один. И даже не на один вызов, а на все вызовы. Смена способа кеширования требует дополнительных действий вовне. В одном нужен, в другом нет. Не понимаю, что вас пугает. Добавлено спустя 49 секунд: Да, надо прикрутить лог. Считаю нехоро вываливать такое наружу, а до лога не дошли руки еще. Добавлено спустя 1 минуту 40 секунд: Без понятния. Данный вопрос решается в конфигурации сервера запретом дёргать все пхп подряд и роутингом запросов на index.php. Если надо обращаться к адресу .php то можно назвать файл страницы .php.php или отвести специальную директорию на сервере, где будет разрешен вызов файлов напрямую. Добавлено спустя 1 минуту 51 секунду: Странный вопрос. В любом месте в любое время можно переопределить этот заголовок любое число раз точно таким же образом. Учитывая что 99.9% запросов именно текстовые, считаю целесообразным заранее объявлять тип содержимого как текст, а переназначать при нужде. Добавлено спустя 55 секунд: Еще третья есть. Не вижу смысла обсуждать это. Они удобные, и читаются легко. Добавлено спустя 48 секунд: а это как это "лениво"? это требует каких-то сложных манипуляций?
нет. просто зачем мне чтото делать если мои скрипты и так работают. и на 5.2 и выше. да, там много вкусного, но мне это пока ненужно. чем мои скрипты станут лучше если я начну заменять array() на [] ? да ничем. вот когда несмогу чтото сделать средствами 5.2 но будет очень нужно - тогда повышу требования версии выше.
просто это делается в два клика мышкой или в одну команду в консоли. я не агитирую. просто мне понравился новый синтаксис массивов и трейты. Я на них крепко подсел и не вижу смысла не обновить пхп. По остальным вопросам можем поговорить подробнее.
почему бы всякие postincludes.php... не перенести сразу в безопасное место? зачем вообще светить их в паблике? инклюдить их можно хоть откуда
решай сам. например у себя, я делаю один каталог напр. protected и там уже все внутренности которые ненужно светить. в идеале конечно я её держу всегда выше чем htdocs. вообще советую разделить еще по функционалу - то что относится к ядру(системе, фреймворку) и то что относится к конкретному сайту. так будет легче ориентироваться. и повторно использовать ядро в других сайтах.
ну мне же придётся перенести вообще все файлы. не проще ли закрыть их в конфиге? к тому же я уже сто лет не видел никаких htdocs. я живу в браке с nginx.
я просто указал на то что файлы системные и конкретного сайта у тебя вперемешку "размазаны' по каталогам. хочешь порядка сгруппируй их. хочешь безопасности выноси их выше или просто запри в каталоге. дело хозяйское
представь что ты сделал два сайта на основе своей pincms. те файлы которые будут полностью идентичны у этих сайтов - это скорее всего системные(pin.php, pincms.php ) а те файлы которые разные для каждого сайта, это файлы конкретного приложения(конфиг, шаблоны, конкретные страницы, снипеты, темы, js и css, каталоги с кешем...)
их всех надо прятать, т.к. в отрыве от системы они не функциональны. Т.е. прятать надо всё кроме картинок, цсс и яваскриптов. Я вижу проще всего сделать это через конфиг веб-сервера. Я правильно вижу?
можно. но т.к. это решается в конфиге веб сервера по принципу закрыть всё кроме /images, /js и /css, зачем лишние телодвижения? Я не против принять вашу точку зрения, просто я не вижу разницы - один хрен придётся в конфиге это закрывать, а то - открывать.
я и не спорю. я просто указал на это. делай как тебе проще. но не забывай что ты хочешь pincms продвигать и популяризировать. а значит она из коробки должна быть максимально защищена, даже если будет в руках не очень компетентного программера. тоесть ориентироваться нужно не на себя, а на самый худший вариант развития событий на хостинге.
Не, я не собираюсь ориентироваться на публику, которая не читает доку перед использованием. =) Это простенький инструмент для тех, кто четко понимает, чего лишается, отказываясь от CMS и CMF и понимает зачем ему это нужно и чем грозит. Я устал от защиты от дурака. Я устал от автоматов, которые делают херню. Вот результат. Добавлено спустя 2 минуты 42 секунды: я приложу конфиг нгинкса с правильными настройками, как вернусь в Москву. Мысль я понял. Пока не вижу иного решения, кроме как конфигурить сервак. Но впредь буду думать всегда о том, чтобы всё прятать-прятать даже если не надо. Правда я увлекался этим ранее, и даже расставлял выключалки во все файлы, если они вызваны вне контекста index.php. Но я пришел к выводу, что это ребячество, и достигается контролем и настройкой веб-сервера, а не защитой от дурака. Этот инструмент я разрабатывал не для дураков. =)
[from] Хорошо. Начни с Pageut. Каждая функция должна отвечать на вопрос "что сделать" и "что именно сделать". Далее можно подумать о наследовании стиля нейминга от соседних функций. Типа, getThat, get_that или GetThat.
Вот и я, как пользователь системы, не понимаю, что put? И почему getStaticPath и GetMinified. И что StaticCSS? ПС: http://clip2net.com/s/6EFbEg
чувак, а ты инглиш как? Добавлено спустя 2 минуты 52 секунды: ты мне картинку с моими методами можешь не постить, я их знаю =) честно Добавлено спустя 4 минуты 19 секунд: чувак, ты пойми. Я мысли не читаю. Что ты хочешь сказать?