Комментарии 216
if ('__AJAX__' == key($_GET)) {
define('AJAX', true);
array_shift($_GET);
} else {
define('AJAX', false);
}
меняем на:
define( 'AJAX', ( isset( $_SERVER['HTTP_X_REQUESTED_WITH'] ) AND ! empty( $_SERVER['HTTP_X_REQUESTED_WITH'] ) AND strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest' ) );
( isset( $_SERVER['HTTP_X_REQUESTED_WITH'] ) AND ! empty( $_SERVER['HTTP_X_REQUESTED_WITH'] ) AND strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest' )
Почему бы не написать просто:
isset($_SERVER['HTTP_X_REQUESTED_WITH']) AND strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest'
или
!empty($_SERVER['HTTP_X_REQUESTED_WITH']) AND strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest'
define('AJAX', strtolower(@$_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest'));
И за array_key_exists (несмотря на большую логичность, и @, и array_key_exists оказываются медленее isset).
Но вот зачем дублировать (и из isset, и из !empty уже́ следует array_key_exists) непонятно.
$ajax = strtolower(filter_input(INPUT_SERVER, 'HTTP_X_REQUESTED_WITH')) === 'xmlhttprequest';
При том, что вы по-видимому, почитатель их, как и все кто использует их в работе, а в них многое делается именно так, по моемУ мнению, поэтому появился мой фреймворк.
<?php
$val = @current($_GET);
define('START', in_array($key = @key($_GET), array('_', 'AJAX')) && 'adm' == $val ? 'admin' : 'front');
define('AJAX', 'AJAX' == $key);
if ('admin' == START || AJAX) array_shift($_GET);
т. е. нужно еще установить константу START в `front ` или `admin` и раз уж этот код присутствует, то я считаю более предпочтительно не использовать ваш технологичный стандартный способ с HTTP_X_REQUESTED_WITH
Я не считаю панацеей стандарты, хотя, без них никак. На первом месте месте должна стоять комплексная оценка всех факторов важных для принятия решений. Люди выпускающие стандарты часто плохо работают. Пример? XMLHTTPRequest — к чему там слово XML? Если взять реальную жизнь: в ответах с сервера только в 5% имеется XML, в запросах еще меньше. Я имею ввиду реальные запросы на всех сайтах сейчас в Интернете. Это моя субъективная оценка, я могу ошибаться. В большинстве случаев передается на сервер application/x-www-form-urlencoded данные, а с сервера приходит либо HTML либо JSON, потому что работать с XML менее удобно. Ситуацию со стандартами надо прояснять, а не удручать.
Аналогично, любители все делать по стандарту, часто навязывают SOAP, там где в этом нет никакого смысла, хотя намного элегантнее было бы применить JSON кодирование.
del
Спасибо за беседу.
Мы кстати говорили не об админке-приложении, а о константе START только.
Мне никто не запрещал делать константу START в конце концов ) И называть мою работу SKY Framework ) Хотя признаю, в SKY Framework очень много сделано по своему и я даже согласен, что в некотором роде он что-то среднее между CMS и фреймворк в общественном понимании. Но у него возможности фреймворк по гибкости, по сравнению с CMS.
Спасибо!
Ну и что вам не нравится?
Я не съезжаю, просто мы вдвоем только говорим, этого мало. Время жалко, впустую будет. Но в честь моей первой статьи на хабре — не пожалею время.
1. Если функция не нравится — пишите свою, она присутствует в коде 1 крыла, так как часто нужна, в PHP альтернативы нет. И меня устраивала до сих пор.
2. Я был бы рад провести публичное обсуждение каждой детали SKY, но в более дружелюбном тоне хотелось бы… Я уверен, что много вещей пришлось бы поправить. Сейчас это только лишь мой личный код.
3. Напишите как изменить ее чтобы стало верно?
4. Вы про фиксированную длину пароля? И про нач. установку генератора случ. чисел? Эта функцию удобно иметь в том виде, в каком она есть. Вы можете ее использовать в обертке и генерить пароли произвольной длины, а можете принудить юзера менять пароль после регистрации…
Нет… разговор в таком тоне, бесполезная трата времени.
deny from all
и третий способ поместить сис-файлы выше корня вебсервера. В SKY можно использовать хоть все 3, хотя по умолчанию сис-файлы в SKY приложении лежат в корне веб-сервера. Если вы считаете, что этот современный способ самый правильный, то почему? Не нужно ничего лишнего писать?
Но на чаше весов сложная структура папок.
Кроме того константа START содержит значение точки входа и от этого зависит работа файлов 1-2 крыла. Т.е. у нее двойное назначение, «убиваем 2 зайцев».
Вариант с ограничением по константе не просто устаревший, он несостоятельный.
В этом файле готовое решение — нажали на кнопку, скрипт пробежался и проверил.
Там кстати, есть сейчас только проверка на .htaccess и index.htm для стат.файлов — нужно будет добавить работу с START. Но раздел Guard есть.
Но вы ошибаетесь, он состоятельный, если сделать скрипт для этого.
В SKY кардинально отличается подход во многом. Я уверен что laravel, symfony умрут как бейсик (ну ладно, фортран), это утопический путь для построения веб-приложений, нужно только время.
Мое мнение, что разработчики трендовых фреймворк, это дяди которые заигрались в игру, они делают чтобы «было красиво», но не слишком задумываются о истинной цели их работы. Они большие, дети.
Когда дело касается больших денег, никто не использует эти фреймворк, а пишут свой код.
Она напрямую не генерирует случайную строку того вида как в SKY функции.
Это: /dev/urandom
вообще, каким образом использовать, если разработка не в Unix?
В SKY все разрабатывается так, чтобы меньше зависеть от стороннего. Даже php.ini настраивать значение для часового пояса, менее удобно, чем просто в стандартной части админки, в готовом веб-интерфейсе выставить его значение (будет использоваться date_default_timezone_set())
Да какая тут может быть критика. Критика это когда "Хм интересно, но я не согласен по паре пунктов." У вас же всё плохо. Нет, серьезно, нет ни одного файла, функции, да практически строчки кода которые были бы нормальными.
Килотонны пафоса зато. Мне сначала было забавно, но чем больше тут от вас комментариев и тем мне страшнее. "Чувак, да что блин с тобой не так?"
Но давайте попробуем "покритиковать". Давайте не будем затрагивать что то уровня использования ООП, eval и глобалы — зло. если с 2012 по 2016(а именно так стоит на сайте) вы не прочли те сотни материалов что существуют и ваша практика так же вам не показала что тут что то не ладно, то думаю в паре комментов мы так же ничего не проясним.
Поговорим о том, что ваш код нарушает ваши собственные тезисы и конвенции.
http://ru.coresky.net/article?standards
В SKY. не используется верблюжья, как и венгерская нотация имен.
но при этом
В SKY. используется система однобуквенных префиксов, например $p_name. Читайте об этом в статье Ядро SKY http://ru.coresky.net/article?core#prefixes
с 12 префиксов!
или
Глобальные переменные и константы, которые предназначены для использования (могут быть затребованы) в любой части кода — пишутся заглавными буквами (за исключением переменных, которые имеют однобуквенный префикс), например $PROFILES. Однако (несмотря на положение переменной в глобальной области видимости), если логически переменная не подразумевает передачу своего значения в отдаленные части кода, а используется лишь в локальной части скрипта, в ее идентификаторе используются прописные буквы, например $i.
И этому идеально следуют такие повсеместно используемые прям центральные глобалы $sky
и $user
и многие другие (http://ru.coresky.net/code)
Да что тут говорить если вы льете кучу пафоса и рассуждений вида
проект всегда должен стремиться к тривиальной простоте, кристаллизация кода должна стать самой важной задачей проекта, важным фактором считать минимизацию необходимости прочтения документации.
но открыв самое простое что обычно есть в проекте — точку входа index.php я очень долго искал откуда же там у меня $user
Это можно продолжать и продолжать. Еще раз, плохо ВСЁ.
eval и глобалы — зло, сказал авторитетный источник и вы поверили и поставили точку и замок на дверь? Чем глобальная область видимости хуже любой другой? в третий раз пишу уже… если в ней выполняется логически один механизм.
eval зло? Если уж совсем так, почему их не выкинут из языка? И в javascript есть и в PHP есть… да везде почти есть. Вот было зло GOTO — его выкинули. Если в eval не подставлять данные из формы, а конструировать код под eval другим кодом PHP, то не зло это совсем.
Вот было зло GOTO — его выкинули
http://php.net/manual/ru/control-structures.goto.php: свистящий_смайлик: А почему goto — зло? Как вы писали бы конечные автоматы без него (я не утверждаю, что это сделать нельзя, но...)?
Такое ощущение, что я попал в начала 2000х:
1) Глобальные переменные, вместо инкапсулированных в объекте или функции
2) Велосипеды, вместо симфонийского http-kernel или (react, amp, guzzle, всё что угодно на свой вкус)
3) XmlHttpRequest вместе с Jquery, вместо нативного fetch
4) Глобальные дефайны
Конечно, это всё утрирование и может для примера не особо подходит, но всё же… Я так писал, когда в школе учился (кроме шуток!).
В глобальной области видимости нет «всего скопом» там только view-переменные для стандартного layout — «main» который удобно поместить прямо в index.php. Что тут вам не нравится?
2) Мой вкус это SKY Framework )
3) не понял, что за «нативный fetch»?
4) Что плохого в том чтобы сделать небольшое количество констант через define? По-вашему PHP имеет возможность их делать, но их делать не нужно?
А вы «разутрируйте» ) Покритиковать легко без аргументов. Что вы плохого увидели кроме тривиально простого кода на вид?
Если просто, то это по вашему плохо?
1) На этот вопрос я не готов давать ответ и рассказывать почему обстрел себе ног из артиллерийских снарядов — это плохо
2) С сообществом из скольких тысяч профессиональных разработчиков? Не могу найти ни на гитхабе, ни в композере. Какой код-коверейдж у него хотя бы?
3) Есть такая функция в JS, которая выполняет Ajax запросы: var response = await fetch('//some.ru', {method: 'POST', body: ...})
4) У вас константы зависят от окружения и от них зависит вся дальнейшая работа приложения. А что делать с юнитами, когда надо проверять логику приложения стартуя каждый раз её с нуля? Обнуляя данные. runkit?
2) все когда-то начинали с нуля, но это не повод говорить, что код из-за этого плохой
3) вы любите сложности? это ваша проблема. Мне проще использовать $.post это короче писать и вполне достаточно для большинства ajax запросов.
4) я не понял… define( ) уже obsolete?
Главная идея — сделать минимальные дополнения к PHP чтобы он стал удобным для построения веб приложений. Вот в Get Started симфони тоже об этом пишут «голый PHP неудобен, сделаем симфони...». Но нужно ли было делать симфони, чтобы PHP стал удобен? Есть вариант сделать намного меньше и лучше.
Я даже не понимаю что отвечать таким людям. Сказать что это полное дерьмо — подумают что высокомерный мудак (простите), аргументировать как-то — через неделю появится новый человечек с очередным "убийцей вселенной". Понятное дело, что никто этим пользоваться не будет, но новички это всё читают и считают что это нормально. А после этого, см. коммент ниже — "Вот почему похапешников снисходительно-насмешливо называют похапешниками". И я полностью с этим согласен.
Это не фреймворк. Это CMS
Кодстайл отсутствует.
Куча констант, глобальные переменные…
Писал много, но стер. Ибо говорить тут не о чем…
Ну почему же он — я уже писал выше про отстрел себе ног из артиллерии, именно это и имея ввиду. Подразумевая, что это очевидно для каждого, но в ответ получил "если не готов дать ответ, то и писать не нужно".
После чего подумал, что продолжать не стоит. У человека (ну т.е. тебя) просто не достаточно опыта, чтобы это осознавать. Не то, что бы я или ваш оппонент выше были самыми умными на планете земля, но прошли достаточный путь развития, что бы смело дисктуровать на темы перспективности архитектуры и качества кода проекта. И я в этом уверен, раз человек упоминает хотя бы предметно-ориентированные подходы в разработке ПО.
Осталось только прислушаться, т.к. 99% (образно) начинали со своей супер-cms/игры/фреймворка/подчеркнуть-нужное.
Где то в своем скриптике тихо мирно выбрал я значит из бд пользователей в $users массив сложил. Потом надо мне их проитерировать, ну я и пишу foreach ($users as $user)
И всё сломал ибо вы такой умный и у вас $user
это глобал который хранит авторизованного пользователя.
Или вы думаете что вы будете итерить в глобальной области видимости обязательно? Есть в SKY Framework MVC — итерите в методе контроллера или модели
Хорошо, на сайте вы предлагаете скачать вот этот исходник для установки:
<?php
define('SKY', 'http://coresky.net/');
if ($_GET && 'img' == key($_GET)) require '_dev/main/image.php';
elseif ($_POST && 'ajax' == key($_POST)) require '_dev/ajax.php';
elseif (!$_GET && !is_dir('_dev')) { # single way to install fresh DEV.SKY.
ini_set('user_agent', 'DEV.SKY.');
file_put_contents($file = 'i_dev.php', file_get_contents(SKY . 'gate')) or exit('Cannot save file');
# remove comment from line below if you want
# exit("File `$file` downloaded. Check it! and open `$file` in browser.");
header('Location: http://' . $_SERVER['HTTP_HOST'] . substr($_SERVER['SCRIPT_NAME'], 0, -7) . $file);
exit;
}
define('START', 'dev');
require '_dev/conf.php';
header('Content-Type: text/html; charset=utf-8');
list($top_menu, $start_html, $login_form, $left_menu) = explode("\n~\n", cell(4));
$TITLE = DB_NAME;
if (AUTH_OK) {
$mess = '';
$u_str = "~user: <b>$u_sky_inet_login</b>" . ($u_profile_code ? " ($PROFILES[$u_profile_code])" : '')
. ', logged at ' . date($u_date_format, $u_last_login_ts);
$start_html .= eval($top_menu);
require "_dev/_$PAGE.php";
if (PAGE == 'settings' || PAGE == 'utility' || PAGE == 'help') echo '</td></tr></table>';
echo_message($mess ? $mess : $u_str) ?><hr>
<div style="float:right">sky. and dev.sky. use
<a href="?help=license">SKY license</a>, see <a href="<?=SKY?>" target="_blank"><?=domain(SKY)?></a>,
2012-<?=date('Y')?> year</div>
<b>DEV.SKY.<?=ver()?></b>, opened in <?=round(microtime(true)-START_TS,3)?> seconds with <?=$sky->qn?> sql queries,
see: <a href="javascript:$('trace',{});window.scrollBy(0,700)">tracing</a>
<script type="text/javascript">var u_str = '<?=substr($u_str,1)?>'</script><br><?php $sky->tail();
} else echo str_replace('%TITLE%', "Login - $TITLE", $start_html) . sprintf($login_form, $u_sky_inet_login, $u_auto_login ? ' checked' : '');
?></body></html>
Буду по строчкам нумеровать:
0) CRLF — не критично, но плохо
0) Скрипт вообще не работает:
PHP Notice: Undefined index: HTTP_HOST in ../dev.php on line 11
PHP Warning: Cannot modify header information — headers already sent by (output started at Warning: Cannot modify header information — headers already sent by (output started at E:\Projects\Chat\dev.php:11) in ../dev.php on line 11
4) проверка на то, что $_GET не пуcтой, проверки на существование вообще нет
4) Сравнение нестрогие сравнения
4) Относительные пути (при изменении рутовой диретории — оно вообще не будет работать)
4) Опускаются фигурные скобки, лишний перенос и всё к чертям ломается
5) см. всё тоже самое, что и на строке 4
7) побочные эффекты — запись в ини… чего?
11) Хедер редиректа? Почему просто не скачать? Или не сделать клон с гита? Или через композер поставить? Зачем это? Ну да пофигу — это просто не логично, но код имеет место быть, за исключением того, что хедеры отправляются без проверки
16) Никаких проверок нет, про автолоад не слышали
17) опять никаких проверок на то, что хедеры уже отправлены
19) функция cell не определена
20) А если баз данных две?
22) А если аутентификации две?
23+) Ну и так далее. Ошибки повторяются
Достаточно аргументов?
сейчас сказать почему у вас не заполнен ключ HTTP_HOST у меня такого никогда не было
4) проверка на то, что $_GET не пуcтой, проверки на существование вообще нет
О чем это вы? пустой массив приводится по типу к FALSE не пустой к TRUE.
Не в консоли он существует ВСЕГДА!
4) Сравнение нестрогие сравнения
А зачем лишний символ писать если он не нужен???
4) Относительные пути (при изменении рутовой диретории — оно вообще не будет работать)
Как раз будет! В SKY все приложения работает в поддиректориях вебсервера
11) Хедер редиректа? Почему просто не скачать?
Смысл такой: копируем dev.php из соседнего проекта (в соседней папке), он скачивает «свежий» установщик DEV.SKY. и вы работаете с новой версией DEV, в новом проекте в соседней папке. Для того, чтобы установить еще один DEV.SKY. вам не нужно ни на сайт идти, ни композер ни клон с гита. Это намного быстрее.
продолжу…
не понял про какие вы проверки? Про автолоад слышал вот доказательство:
http://ru.coresky.net/code?main/sky.php
см. метод SKY::autoload()
инициируется так: spl_autoload_register([$this, 'autoload']);
Вы вообще-то смотрите приложение DEV.SKY. это не код фреймворк это готовое приложение и как хочу быть не может
0) Потому что я запустил скрипт через консоль, о чём я и написал
4) Я запустил из консоли
4) Ну наверное потому, что это лучше всегда. Но в данном случае не критично
4) Ну возможно, проверять опять не хочется, простите
11) Да ладно, наберите composer create-project
— это всё, что нужно, чтобы поставить любой существующий современный фреймворк.
16) Тогда зачем реквайры?
20) А почему фреймворк зависит от БД? А что делать без БД? А как использовать лишь драйвер БД вашего "фрейма" без остального? А как запустить из под демона (реалтайм скрипт из консоли в памяти), а как...
Вообще-то если видете $_GET то должно быть понятно что в браузере нужно )
1) В симфони (ни сборке Standard, ни в фрейме) нет index.php
2) Там есть app/console для операций, включая установку всякого (подразумевается генерация кода)
3) Даже запуская app.php в консольке — вы не получите никаких ошибок, просто пустой объект реквеста
4) Установщик у симфони, как и любого современного фрейма — консольный. Просто потому, что фрейм не обязан зависеть от http и уж тем более браузера.
Ну конечно намного удобнее работать с приложением в консоле, а если браузер покажет все «на ладоне» то это плохо. Вы сами себе верите?
Нет все-таки приколько играть в игру «пусть будет красиво». Выдумываем какую-то абстрактную каноническую истину без особых оснований и следуем ей. Прекрасно.
А в SKY установщик зависит, насколько это плохо?
Очень плохо. Это значит что на сервере его не стартануть. Представляете — на серверах одна консоль. Браузеров нет, вообще ничего нет, только открытый вовне порт на 80. А иногда и этого тоже нет и сервера тоже нет — скрипт лишь реализует отдачу отдачу данных, например в некоторых частях RTB систем. А ещё это может быть ботом, который мониторит что-нибудь, что-бы оно не упало и поднимает процессы и стоит отчёты. Или… Вариантов много и если нужно сделать веб-страничку — фреймворки нужны лишь когда проект сложный, а не уровня бложика на вордпрессе.
Вы изобрели высокосвязную CMS.
Приложение DEV.SKY., файл dev.php, от которого вы смотрите, де-факто предназначено для работы только! на рабочей станции программиста (чтобы вы поняли, это альтернатива консольной утилите от симфони и веб-приложению! Yii для генерации CRUD шаблонов). Кстати в Yii надо сделать del ему по вашей логике тоже. Это два.
Читайте статью «Нужны ли сапожнику сапоги?» http://ru.coresky.net/blog?id42 это три.
О, это вообще шедевр!!! В споре, скинуть ссылку на свой же опус, на своём же сайте. Это, это… гениально. По моему тут уже был подобный чел. G-Max зовут или как то так, он тоже говорил, что все вокруг не правы, и его вариант ну просто единственно верный.
Еще неплохо было бы все компьютерные игры портировать в консоль )
Ну вы сами себя слышите? Если есть разные опции… Есть возможность визуализировать процесс установки в браузере (это сапожник с сапогами), по вашему консоль удобнее? А как насчет установщика, например Drupal, который работает в браузере? Портировать в консоль? Вы скажете это не фреймворк, а приложение, у симфони шире область применения.
Ну прочтите определение для чего изобретен язык PHP — для работы с браузером, а то что он работает в консоле это дополнительная возможность, которая всегда идет номером два и не подразумевается что номера один нет.
И где же такие сервера, что PHP есть, а веб-сервера работающего на 80 порту нет?
А вообще пока мы тут пытаемся объяснить где автор не прав, он семимильными шагами приближается к кнопке «сделать пиздато», ой даже не кнопке, а к голосовой команде компьютер сделай сайт.
https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BF%D1%80%D0%B5%D1%80%D1%8B%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B8%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F
testing — переводится как тестирование
deploy — развертывание приложения
phpunit — фреймворк для тестирования
Удовлетворил знаниями?
К примеру есть этап тестирования, когда прогоняются тесты с помощью phpunit, затем может идти этап проверки на соответствие code style и т.д.
И для этого всего абсолютно не нужен веб-сервер. Но в вашем же случае оттестировать приложение без веб-сервера будет, наверно, не возможно.
Вот скажите у Вас «фреймворк» проходит автоматические тесты?
Список литературы, которые обязательны, на мой взгляд, для изучения Вам:
1. http://designpatternsphp.readthedocs.io/en/latest/README.html
2. http://www.php-fig.org/psr/psr-2/ и на русском http://svyatoslav.biz/misc/psr_translation/#_PSR-2
Ну не нужен веб-сервер… это что панацея сделать так же? В SKY Framework всегда нужен, кроме консольных скриптов.
Это философский вопрос — как лучше. Выше мне минусов наставили за то что @скрытие_ошибок медленно работает, а навязать ненужный код, это правильно.
не зависит.
А что делать без БД?
Веб приложений без БД не бывает сейчас. Вы вообще хоть немного вникли в SKY? coresky это всего лишь 3 файла объемом 54 килобайта
Change HTTP_HOST to SERVER_NAME to prevent problems with client not setting HTTP_HOST
Из-за таких похапешников и хейтят похапе
«Я хочу гасить ошибки, я буду их гасить.»
«Я написал лучший в мире фреймворк, у которого есть установщик. Потому, что я так хочу»
«Это фреймворк. Я сравниваю его с друпалом»
«Раз вы мой фреймворк тут обкакиваете, значит сами ничего не умеете»
Вы попросили критику — вам дали критику. На критику надо реагировать нормально, но Вы же кричите плюясь слюной, что мы все ничего не понимаем и Вам плевать на наше мнение. Я сделал так и всё.
Для чего тогда Вы пришли сюда?
Приводите в пример симфони. Но я почти уверен, что про симфони Вы знаете не больше, чем говорит вика.
Пришли на хабр показать свой продукт. Так принимайте критику спокойно, вдумываясь, и анализируя
Окай…
1. Гашение ошибок… Ошибки нужно не гасить, а устранять.
2. Глобальные переменные — плохой подход. И это не я утверждаю.
3. Определять что-то константами, и тем более проверять константы в файлах класса… Это в 2000 году было нормой
4. Кодстайл… Почитайте PSR
5. Я не увидел там никакого MVC. Пародию увидел
6. Спагетти-код
7. Глобальные переменные везде. Я про $_GET и иже с ним
Это кто сказал? Почему все обязаны вам верить? По-видимому здесь на хабре пришли к такой мысли все… И это авторитетное мнение… Я не делал тестирование скорости работы @ если реально сильно медленное — можно в будущем устранить, а лучше пофиксить PHP, чтобы работало быстро. Если это рекомендация никогда не применять @ ввиду возможной запарки и создания себе сложной жизни и невозможности локализовать ошибку, — то это вопрос философский… Я ставлю подавление ошибок ТОЛЬКО в тех местах, где явно не будет проблем с локализацией ошибок, аналогично использую eval( ).
То что де-факто считается зло в сообществе людей с взглядом как у вас, дает ощутимые преимущества в краткости и простоте кода.
Я понимаю, что «много на себя беру» ставя под сомнение то, что eval и @ зло, как считается в вашем привычном кругу. Но на первом месте у меня не следование общепринятым нормам, а открытая логика. Я считаю, что если программист не может применить @ или eval( ) безошибочно, чтобы не сделать себе зло, то он и так не будет способен программировать, «делать вещи».
Реальное зло — оператор GOTO доказано математически и выброшено из всех языков программирования, eval же везде есть, так что это сомнительное зло.
Проблема с Eval'om всегда одна и та же. В неё все равно кто то протащит исполняемый, но не по назначению код.
А собака(@) это как газетку на говно постелить. То есть его не видно. Но воняет и остальные не поймут почему.
::PROC это вообще константа. Используется eval чтобы сократить код в index.php сделать его простым. ::PROC это стандартный константный код который нужен для построения сайтов.
<? eval($sky) ?> $sky это объект, тут используется __toString магический метод, чтобы вытянуть $sky->code, который генерируется таким образом, что там не может никак оказаться произвольный код, так как опять таки он состовляется из разных константных кусочков строк. Каждое $sky->code .=… вот такое добавление проанализировано мной на предмет того, что случайного кода быть не может.
Да там евалов просто море. Вон и модуль пагинации, который по моему не все реплейсит.
А еще там есть лютейший extract без EXTR_SKIP.
Который может вообще пустить по банану и перезаписать любую переменную, которая потом так же прилетит в require или eval. Но я не смог это проверить, ибо ваша поделка не запускается на PHP 7. Совсем.
Насчет PHP 7 — это серьезный прокол, не тестил. Обещаю в ближайшее время исправить. В этом проекте это задача номер 1. Если ничего не случится с моим свободным временем исправлю быстро. Но прошу вас меня понять: несмотря на то что coresky это 3 файла всего лишь размером 45 кБ, работы в проекте чрезвычайно много, а помощников у меня мало.
Можно спросить в каких реальных проектах используется данная система?
Видео на главной странице не впечатляет, блог проще создать установив вордпресс. Результат будет более юзабильным, а время запуска блога будет таким же
Это вменяемый функционал и нужный. Зачем его фиксить, он работает как надо. Это вы используете его не правильно.
«Зачем покупать новую машину, если есть Москвич 73 года выпуска. Он же работает. Ну и путь он троит, дымит, чихает, зато едет. Тушку мою перевозит и ладно. А те, кто критикует — просто ничего не понимают. Ну и пусть нет запчастей. Я возьму деталь от трактора, подточу на наждаке и загоню молотком. А чтобы не отвалилось — надежно приклею скотчем»
Вы путаете грешное с праведным. В том «что не вы утверждаете» имелось ввиду «не вносить в глобальную область видимости переменные разного функционала», так как опять таки сложно будет локализовать ошибки, да и не верно это просто логически. Так нет у меня «всего скопом». Пятый раз пишу… Чем глобальная область видимости хуже метода класса, в которой, в вашем фреймворк расположен код LAYOUT. А в SKY LAYOUT расположен в глобальной, и что тут не так?
Иногда новое это хорошо забытое старое. А я считаю, что у нынешних трендов нет будущего. Потому как забрели «далеко в лес» играясь с разными вещами без оснований.
Единственное, что позволю себе заметить:
Новый фреймворк чаще всего создается, когда разработчик нового не приемлет многое в имеющихся.Не «когда он не приемлет» чего-то, а когда ему не даются существующие технологии и обкатанные стандарты, и ему не понятно, по той или иной причине, зачем были сделаны те или иные вещи, и что сделаны они были далеко не глупыми инженерами. Вот тогда и появляются новые движки, библиотеки и фреймворки, решаюшие уже решенные проблемы и собирающие уже давно пофикшенные баги.
Ну, правда, все-таки 2016 год на дворе.
Лично я этого не обнаружил
Оффтоп. Вы забыли про важное выражение «принципиально новый»!
main/sky.php, Class Sky но почему у методов не объявлена видимость. Где док.блоки.
mysql_* Deprecated
PHP 7 — вообще не запустилось ничего.
Дальше даже проверить не смог.
А вы не в курсе? если не объявлена, — значит public
Спасибо за веселую пятницу. С коллегами позабыли о работе, разговоры только о новом фреймворке и его уникальном авторе)))
В общем доказывать вам что-либо нет смысла. Все доводы и критику Вы воспринимаете в штыки, типа:
«Эй, поц, есть телефон позвонить? А если найду?»
Вы не задумывались о том, почему фортран умер?
Да ровно по тому же, почему не производят Москвичей 73 года
Ровно по тому, почему умерли ламповые телевизоры, компакт-кассеты и прочие пережитки былых эпох.
Вы же со своим кодом остались в тех временах, когда было нормой defined('SITE_NAME') or die('Direct access');
Ну что же. Нам остается только пожелать Вам удачи во всех Ваших начинаниях и продолжениях.
ЗЫ. Уж очень хочется глянуть в то время, когда современные технологии программирования умрут, как фортран)))
Как я должен реагировать на ваши насмешливые посты? Как вы реагируете если бы оказались на моем месте? Если уличение от авторитетного источника — то понятно, и я так же. А если не от авторитетного? Разве я не толерантный? )
Вы меня простите, но я вас не знаю и вы мне не авторитет. Даже более того, я почти уверен что не авторитет. Авторитет для меня не тратил бы время на то, что тратите вы здесь. Это номер 1 и этого достаточно.
Если ваш ответ: в глоб. области образуется помойка. Но сразу другой вопрос: а если в глоб. области переменные одного лишь функционала! Чем хуже она области видимости внутри метода класса??
Только прошу — логику. Ничего кроме нее. Ответ нельзя потому что все так говорят — не подходит.
Типичный пример на сайте используется js библиотека prototype, клиент просит поставить виджет его партнера, в виджете используется jquery. Производитель виджета не позаботился о безопасном использовании библиотеки jquery и код сайта ломается после загрузки виджета.
Это раз.
Разработчик который будет работать с вашим кодом должен ознакомиться со всей лапшой кода вашего ядра и найти все эти глобальные, чтобы найти почему код поломался. Ну или заранее чтобы не прострелить себе ногу.
Магические цифры в коде приложения, допустим разработчик не открывал файл с этими цифрами год, такое часто случается. А потом открывает и видит -23, 96, 15 передаваемые в параметры функций. Что это за цифры? Почему -23, а не -26?
Совершенно аналогично вы можете в методе объекта создать лок. переменную, а потом забыть о ней и переопределить.
В SKY Framework с MVC паттерном, код приложения полностью размещается в методах класса и пользователь глобальную область не трогает. Кроме переменных в файле VIEW т.е. в main layout но они все с префиксами.
Еще аргумент: coresky это 45 кБ кода, подразумевается, что разработчик SKY полностью им владеет.
Практика: я несколько лет делаю сайты на SKY Framework — никаких проблем описываемых вами нет абсолютно. Справедливости ради скажу, более 10 лет назад, подобные проблемы были, но они несложно решались. И не так страшен рак как его малюют.
Я понимал, еще давно, что работая в глобальной области видимости я делаю лишний повод покритиковать себя. Но тривиальная простота кода и прозрачность перевесила в моем решении использовать такой подход.
function strand($n = 23) {
$str = 'abcdefghjkmnpqrstuvwxyzACDEFGHJKLMNPQRSTUVWXYZ2345679'; # length == 53
if ($n != 7) $str .= 'o0Ol1iIB8'; # skip for passwords (9 chars)
for ($ret = '', $i = 0; $i < $n; $i++, $ret .= $str[rand(0, 7 == $n ? 52 : 61)]);
return $ret;
}
52, 61 — это просто вручную посчитано кол-во элементов массива, он не меняется.
7 — пароль нормального уровня сложности, энтропии. Если хотите считайте начальный пароль, позже пользователь переопределит его.
23 — куки нормальной энтропии, чтобы не быть подобранной, но чтобы и не быть очень длинной
Эти цифры сейчас проставлены мной интуитивно. Идеально математически просчитать кол-во вариантов и выбрать.
Да почему же в штыки?
По тому. Вам говорят подавление ошибок и глобальные переменные — это зло. Вы утверждаете обратное, ударяя себя в грудь, что Вы правы.
Мне то всё равно, что и как вы там у себя 10 лет проектируете, в авторитеты к вам я не стремлюсь. Более того, уверен, что к понедельнику я про эту тему уже и не вспомню.
У вас своя правда, вот только чужое мнение вам не интересно.
Доказывать вам тут ничего я не собираюсь. Опять же, ваше дело. Как хотите так и пишите.
Но… «Есть же какие-то вещи» (с) Шуренберг
Я знал давно, многие вещи о которых вы говорите, о глобальной области и т.д. и сознательно их нарушил. Я хотел, чтобы вы посмотрели, чего можно достичь если нарушить их. А вы просто шлепнули меня ими. А чтобы увидеть чего можно достичь нужно более внимательно присмотреться к проекту, а не «одним глазом».
Посмотрите в историю: незыблемые стены тоже иногда рушатся, просто на все нужно свое время. А новое это часто хорошо забытое старое.
Если выбрать другое решение — эти минусы стали плюсами. А граблей, которыми все пугают, пока не встречал, если все сделать аккуратно.
Это проект для программистов
Интересно. Когда спадет хабраэффект, насколько упадет количество скачиваний Вашего проекта)
А вы не в курсе что не хорошо не договаривать. Сказал function — говори и видимость
А причина простая — вместо того, чтоб изучить инструмент, с которым работаешь (в данном случае php), люди бросаются писать решение под себя, потому что порог вхождения невысок и позволяет получить результат быстро, пусть и кривыми способами, а известные решения кажутся слишком сложными из-за непонимания базовых принципов. Ну а после — так и используют свое решение, не пытаясь даже смотреть в сторону других, с большим сообществом, оттестированных и проверенных временем.
Если автор не тролль, что маловероятно, то пусть почитает:
http://getjump.me/ru-php-the-right-way/
https://getcomposer.org/
http://www.php-fig.org/psr/
Серьезно? Это в каком информационном "коконе" вы прибывали что приведенные ссылки для вас оказались в новинку и вы теперь "думаете что делать". Неужели вы с 2012ого по 2016 (как указано на сайте вашего творения) не слышали о composer, PHP FIG и "постулатах" right way.
Или я не верно понял ваш комент...
По моему мнению слишком большой ценой (увеличением, осложнением, меньшей производительностью, меньшей прозрачностью кода) мы со 100% вероятностью всего лишь гарантированно не получим ошибки одного типа. Это муха против бомбы можно сказать. Но я понимаю, что это может оказаться очень серьезно в самый неподходящий момент… В общем я в размышлениях пока что.
Обязательно хочу прочитать и сравнить свои мысли с первоисточником по поводу глоб. области, eval и @подавлении ошибок. Просто принять без осмысления наверно не смогу. В общем, мне сложно описать, что я чувствую сейчас и какой выберу путь, но спасибо вам за общение, оно было не зря однозначно. Если рассмешил — на здоровье, если отнял время — sorry.
Буду искать альтернативные решения наверно, например, в сторону анализаторов кода
Локально: https://plugins.jetbrains.com/plugin/7622?pr=idea
Удалённо: https://scrutinizer-ci.com/
Но устраивать «революцию» Вам ещё ого-го как рано. То, что Вы предлагаете — для большинства use-case'ов — не лучше существующих решений, которые Вы критикуете (хотя в каких-то use-case'ах может в чём-то оказаться и лучше, не спорю). И большинству людей Ваш фреймворк не нужен (даже дописанным и отлаженным). В лучшем случае, Вы настрогаете на этом фреймфорке пару-тройку сайтов и приобретёте опыт. Но чтобы идти в массы с ним — зась (и не потому что сам фреймворк сырой и недописанный, а потому что Ваше понимание проблем и видение их решений ещё далеко до созревания).
У Вас (кажется, могу ошибаться) есть ум и самоуверенность. Это хорошо; эти два качества редко бывают вместо (часто умные люди неуверены и наоборот). Но то, что Вы предлагаете пока, очень сырое.
бред же, известные решения кажутся слишком сложными из-за того, что они слишком сложны;
Не решения сложны, а порог входа в php не очень высокий. Можно сделать как в старые темные времена прям в странице sql-запрос и вывод в браузер и это будет работать. Просто же. А вот чтоб понимать чем такие действия грозят и как трудно это потом поддерживать будет — нужно чуток знать как в целом все работает. Потому поначалу и кажется, что шаблонизаторы, контейнеры зависимостей, orm и т.п. — лишние звенья. Зачем они нужны, если в конце все равно пользователь получил страницу?
Если новичку проще втюхать SQL-запрос (вдумайтесь — SQL-запрос!), чем заюзать ORM — значит интерфейс ORM сложнее, чем должен быть; точка; другое дело, что PHP, возможно, не позволяет реализовать ORM с более простым API (автор ORM уже сделал всё, что мог, и это не его вина, что проще не получилось).
Новички юзают уродливые способы не из какого-то там принципа; а просто потому, что способы, которые решают задачу более правильно, имеют более сложное API, чем уродливые; вот и всё.
Новички юзают уродливые способы не из какого-то там принципа; а просто потому, что способы, которые решают задачу более правильно, имеют более сложное API, чем уродливые; вот и всё.
и чем это отличается от моего высказывания — «известные решения кажутся слишком сложными из-за непонимания базовых принципов»?
Часть «принципов», стоящих на пути к правильному решению, являются более-менее интуитивно понятными и осваиваются на лету.
Часть «принципов» вообще не имеют отношения к решению задачи, а возникают из-за того, что автор библиотеки перемудрил (это необязательно его вина; он мог делать как мог просто в условиях данного языка/платформы; т.е. что в условиях данного языка/платформы задача не решается просто и правильно одновременно; но для новичка это лишняя нагрузка).
Базовые принципы «right way» говорят: не создаем ничего в глобальной области видимости, не используем eval(), не применяем подавление ошибок @ (3 правила X), — так мы гарантированно избежим ошибок определенного вида! Я очень согласен с этим и поддерживаю. Но «right way», имхо, принебрежительно отнесся к тому что «на обратной стороне луны».
Я пришел к вам «подвинуть» «right way» (напрасно вы так воспринимаете -«лососнуть тунца»). Многие просто не понимают сколько мы теряем, приняв 3 правила X и что есть на обратной стороне луны. А там — тривиально простой код, намного более высокая производительность и еще много чего хорошего. Я просто чувствую и уверен что «right way» неверен, и у вас неверные весы. Вы отдали предпочтение тому, что менее важно. Тем не менее, я часто сталкиваюсь с программистами, которые с открытой душой приемлят «right way» и я не знаю, почему вы не видите то что и я. Благодаря геометрично увеличивающейся сложности, я считаю «right way» утопичен. И даже дело, не в трех правилах X, возможно в SKY что-то таки следует менять из трех правил X. Я пришел к вам показать новую работу и мое видение построения технологии для получения идеального кода (хотя сама статья была только о шаблоне CSN-Ajax). Вы увидели не следование мной 3 правилам Х и сразу же пустили работу в топку. Я могу делать допущения, когда изучаю новый предмет. Того же мне хотелось видеть в вас, обсуждать детали SKY Framework в спокойном тоне. Я не призываю никого, бросить симфони и начать работать в SKY, это может быть просто хобби, пока не появится «right way++». Какой бы у вас не был IQ вы не сможете смоделировать 5 летнюю работу с SKY Framework в уме, чтобы адекватно оценить работу и говорить о нем в таком тоне, в каком говорите. Хотелось бы мне увидеть ваш код, который вы (или кто там) писали в 10 классе, я уверен — ну не писали вы так… я бы взлянул и указал на 100 явных недостатков. Знал я одного вундеркинда, он первый находил к чему придраться, а когда я взглянул в его код — путаница…
Двигать авторитетов можно и нужно, иначе бы слово «прогресс» было бы пустым звуком и новые знания не рождались бы в муках. Джордано Бруно сказал всем что земля круглая и его сожгли, так как пришел без доказательств. Энштейн подвинул Ньютона, но пришел с доказательствами — его сделали дилехтором ). Я уверен на 100% последнего можно и нужно также двигать и любого авторитета в науке. Я даже верю в путь: а) нет никакой темной энергии и материи; б) все дело в
http://ru.coresky.net/blog?id43 — дотошно вникните в суть статьи, если вы молодой физик. Теорию меняем, формулы новые, объясняем движение звезд в галактиках, расширяющуюся вселенную и еще пару подтверждений в опытах. Извиняюсь за оффтоп, — не удержался чтобы не написать.
В «right way» точного доказательства нет и быть не может, как и в SKY way… Спор может разрешить только опыт и конструктивная дискуссия профессионалов.
Предостережение для молодых программистов: если вы хотите крепко стать на ноги — работайте только с «right way», спрос на рынке труда именно таков. Но если вы крепко стоите на ногах — приглашаю вас на мой проект. Изучать, пробовать, экспериментировать, творить вместе. Сначала как хобби.
«right way» принебрежительно относится к увеличивающейся сложности фреймворк, постоянно выбирает сложное решение, даже там где подошло бы простое. Мое субъективное мнение такое: большинство программистов получает удовольствие от своего кода: «вот как я круто написал, красота то какая, кругом одни классы и в том же духе»… А ничего крутого в куче классов нет, все гениальное просто. Я не знаю как объяснить вам, что между кодом который выглядит на вид одинаково просто (так же как и вы писали в 10 классе) может быть огромная пропасть. Ну пусть даже не в самом коде, а в подходе, в пути развития.
Я считаю в программировании было 2 прорыва: первый язык С, второй — языки высокого уровня. Кто там первый полноценно сформировавшийся? Perl, Java? Не важно. Я уверен точно — «right way» прорыв не грозит. Языки высокого уровня: убрали препроцессор, автопривидение типов, удобные типы данных и т.д. только упрощения (в сравнении с С/C++) с ориентацией на web. «right way» рубит сук на котором сидит — нещадно увеличивает сложность.
http://ru.coresky.net/roots?id26
http://ru.coresky.net/roots?id33
«right way» имхо, выдвинуло некоторые теоретические догмы и им следуют упуская важное. Так и понятие «full stack framework» в некоторой абстрактной теоретической плоскости. А зачем нам теория? Должны быть практические догмы. На симфони вообще невозможно построить приложение DEV такого же компактного уровня. Как на симфони построить компактное приложение?
На сайте симфони написано — будет PHPBB использовать симфони, но только прошло 3 года а новой версии PHPBB на симфони нет. (я где то читал что собрались форум PHPBB переписать на симфони еще в 2013 году) Команда профессионалов переписывает форум уже 3 года. Браво симфони, работать видимо команде PHPBB легко и приятно, кто только у них придумал переезжать на симфони). Эти ребята всегда писали в глобальную область видимости и сейчас наверно «балдеют» ) Их работа от этого не была менее популярна.
Я работал с Zend.1 больше года
Из списка «ваших трендовых фреймворк» это все, но я считаю этого достаточно, чтобы говорить о том, что я имею о них представление.
Увы, но этого недостаточно — года наверно с 2013 популярные фреймворки становятся компонентными, даже до этого в 2012м году появился композер и zend 2.0, так что именно современные стандарты вы, судя по всему, пропустили.
А там — тривиально простой код, намного более высокая производительность и еще много чего хорошего. Я просто чувствую и уверен что «right way» неверен, и у вас неверные весы
ваш «тривиально простой код» не работает в 7й версии, а активная поддержка 5.6 закончится в конце этого года, что делает ваш код не особо пригодным к продакшну. И не думаю, что ваш код будет очень быстрым, сравните производительность с phalcon.
Я пришел к вам показать новую работу и мое видение построения технологии для получения идеального кода
$_POST['login'] = $user->login;
$top_html .= '<div id="content"><table width="100%" height="100%"><tr><td align="center">';
$top_html .= form($_POST, ['login' => array('', 'Login'), 'password' => array('', 'Password'), array('submit', 'post')]);
echo strtr($top_html, ['%TITLE%' => 'Admin login form', '%HEAD%' => '']) . '</td></tr></table></div><hr>';
echo tag(a("<b>$s_title</b>", LINK) . ", the <b>SKY</b> app, see " . a('www.coresky.net') . ', years 2012-' . date('Y'));
ничего личного, но когда кто-то на работе пишет в подобной манере, я говорю что за такое нужно сильно бить по рукам. это никак не состыковывается с понятием идеального кода.
«right way» принебрежительно относится к увеличивающейся сложности фреймворк, постоянно выбирает сложное решение, даже там где подошло бы простое.
ок, не нравятся вам фреймворки, или же не было задач сложнее сайта-визитки, где они бы помогли. Куча библиотек сейчас есть для всего, что в голову ударит. Почему бы не использовать их?
Для мелкого сайта нужно не так то много:
роутер
контейнер зависимостей
шаблонизатор
сборщик запросов, чтоб не писать запросы вручную
что-нибудь для обработки запросов-ответов
ну и если очень нужно что-то делать по расписанию — что-то для консольных команд
И будет все просто, быстро и по современному, и расширять будет удобно, да и сами не запутаетесь в куче глобальных переменных и eval'ах.
Посмотрите материал по ссылкам — каждый по себе компонент очень прост, протестирован и хорошо выполняет свою задачу.
Даже модули можно будет сделать очень просто, опираясь на Aura.Di и заводя для каждого мелкого модуля свой конфиг — так можно будет перетаскивать нужное из проекта в проект.
А как в Ваше творение их впаять — я не знаю, надеюсь вы приведете пример.
ваш «тривиально простой код» не работает в 7й версии, а активная поддержка 5.6 закончится в конце этого года, что делает ваш код не особо пригодным к продакшну. И не думаю, что ваш код будет очень быстрым, сравните производительность с phalcon.
Это просто моя (согласен важная) недорабока, которая будет исправлена. Мы сейчас говорим, о фундаментальных вещах, об общем подходе, стратегии и архитектуре. С вашей стороны глупо, простите, приводить как аргументы то что вы написали. SKY Framework также несложно упаковать как расширение для PHP, переписать на С/C++ и только тогда уж нужно меряться по производительности с phalcon.
Если нужна производительность — то можно взять его.
я не то что верю, я знаю, что сайты на SKY Framework могут масштабироваться до очень сложных и много функциональных приложений.
есть примеры таких приложений?
вот вы пишите про новый подход, что у вас норм код, так что вот это блть значит?
(string)@$GLOBALS['sky']->mem[$char][3][substr($name, 2)];
у вас везде подобное, везде магические числа, о подсказках от ide можно забыть, описаний функций/методов нет
function strand($n = 23) {
$str = 'abcdefghjkmnpqrstuvwxyzACDEFGHJKLMNPQRSTUVWXYZ2345679'; # length == 53
if ($n != 7) $str .= 'o0Ol1iIB8'
и вот такое почти везде. вам то код понятен и кажется простым — вы ж его автор, тупо запомнили. Как мне это дело протестировать? И что сложного в тех ссылках, что я привел ранее?
гибкость, говорите?
if (at('0 23')) lsql("delete from visitors where dt_l + $s_clear < now()");
at('59 23') && sql("+select 'do work once at the end of day'"); # sample2
if (at('1 0')) $sky->s_email_cnt = 0;
if (at('3 3')) require 'main/c_sitemap.php';
как мне сюда отдельное задание добавить? а если заданий будет 100?
$txt .= '<style type="text/css">
.tbl {width:80%;border:1px solid silver;margin-top:10px} .tbl td {vertical-align:top;padding: 0 5px}
.dvx {width:80%} .ltd {width:30%;border-right:1px solid silver}
.fr {float:right;font-weight:bold}
</style>';
}
прелесть
в общем жду примеров сложных приложений на этом чуде. да даже не сложных, хотя б новостной портал
Если что, классы и объекты быстрее массивов и кушают меньше оперативы, ну и два — локальные переменные обрабатываются быстрее глобальных. Если вы уж говорите о скоростии потреблении — я не увидел ни строчки, ни асинхронного кода и ни одного упоминания корутин.
И да, при упоминании "right way" — вы как-то пропустили тот момент, что код, написанный по его правилам не требуется изучать, достаточно понять интерфейс взаимодействия с системой, а что там внутри — изучается либо для самообразования, либо при непредвиденных ошибках. Более того, при написании "right way" никто не мешает поменять этот поломавшийся код на другой, не держа в памяти ничего другого, кроме того же интерфейса этого модуля.
Вам бы в JS податься. Там глобалы — это норма, благо их потом модули (system, common, amd, etc) инкапсулируют так, что никто нигде не поломает.
Ну как же, слоган топикастера — будущее за простотой. Запилит модули а-ля is-array из пары строк и всякие left-trim и ими буду пользоваться!
… или стойте, не говорите что....
Ну ладно, раз ниша занята — появится фреймворк isJs из одной строчки: export default const isJs = true;
!
Ой, кажется я его уже написал. Прости coresky готов передать его полностью тебе. Только тесты надо дописать.
Уважаемые JS-ники и coresky, не воспринимайте всё близко к сердцу, это лишь ирония
«right way» и трендовые фреймворк, имхо, это просто игра запутавшихся программистов, которые играют в некотором нереальном поле. На фоне получения удовольствия творчества и довольствования своими способностями, вы не сильно обращаете внимание на реальность. Несмотря на высокий IQ у гуру «right way», вы не можете сбросить шелуху из мыслей и посмотреть на то что происходит чистым взлядом. Имею ввиду то, что я бы назвал «open your mind» (фильм «Вспомнить все»)
Вещи нужно создавать, когда в них есть потребность. По этой причине, я считаю бессмыслено иметь ORM, как дефолтный способ работы с БД, в ваших роутерах просто нет необходимости. Компилируемые шаблонизаторы просто не нужны, потому что шаблоны PHP сами по себе идеально могут справляться с поставленной задачей. Идея twig интересна, но не нужна. И так далее, список могу продолжить.
Из трендовых фреймворк, я отдал бы предпочтение Yii по причине PHP шаблонов и другим вещам. Но критика в его сторону: в примерах которые он приводит, много ненужного кода в файлах представлений. Этого можно и нужно не делать.
MetaDone, я не то что верю, я знаю, что сайты на SKY Framework могут масштабироваться до очень сложных и много функциональных приложений. Результат при этом будет достигаться быстрее и качественнее чем, например, на симфони.
структура наименований классов — имя вендора/имя пакета/пространство имен пакета/название класса
такая идеология скоро создаст на пакажист помойку и будет трудно найти хороший пакет так как будет представлено много альтернативных. Имя вендора не имеет ничего общего по отношению к функционалу который он предоставляет, поэтому не должно быть включенно в названии.
Если бы вы «изучили инструмент», то поняли бы, что работа с двумя БД одновременно не является частым случаем (точно менее 30% покрытия) и поэтому в clear-cloud файл не включена. Мое видение, если вам нужно работать с postgresql — просто меняете файл main/sky.php который является портом файла для mysql (clear-cloud). Если работаете с 2 БД одновременно (как раз я работал на Zend так, и считаю их решение уродливым), то вы подгружаете файл третьего крыла (редко употребимый код) и автозагрузчик его использует.
При работе с 2 БД, как правило 1 БД основная и с ней удобнее работать так же как и в приложениях с 1 БД.
![image](https://habrastorage.org/getpro/habr/comment_images/dbc/1f6/e86/dbc1f6e869ec62bd303bb505b6c04a4d.png)
Я только что установил PHP 7 — все нормально работает. Вроде бы в «right way» у вас short_open_tag должен быть Off — включите его, возможно в этом дело.
Вы просто троллите меня? )
такая идеология скоро создаст на пакажист помойку и будет трудно найти хороший пакет так как будет представлено много альтернативных.
https://packagist.org/statistics — 112k пакетов и вроде норм все.
Имя вендора не имеет ничего общего по отношению к функционалу который он предоставляет, поэтому не должно быть включенно в названии.
Оно и не имеет, только позволяет безболезненно выбрать альтернативы реализации чего-либо. Это как в старые темные времена — префиксы названий классов, что-то типа XzUltraGoodMysqlQB превращается в элегантное Xz\UltraGood\Mysql\QB.
Согласитесь, использовать QB удобнее, чем XzUltraGoodMysqlQB.
Вам надо познакомиться с сообщником из публикации https://habrahabr.ru/post/283166 — у вас даже код похож, так что скооперируетесь.
Я у вас спросил «А зачем ORM вообще?» Первое, что вы мне сказали — короче запись, делаем $user = new User и так мы добавляем нового пользователя.
Первое, что я сказал — это возможность не зависеть от БД в принципе. Одной строчкой переключить с неё, на работу в оперативке, например (это реальный пример из моего опыта).
Про User — было уже второе.
Третье было уже про предметно-ориентированные подходы (должно было быть), но вы положили большой болт на то, что бы кого-то выслушивать и пытаться понять, стали доказывать свою точку зрения, так что я не стал распыляться. Не имеет смысла говорить что-то тому, кому это не интересно и тому, кто не хочет учиться, остановившись в развитии больше 5ти лет назад, о чём я упоминал, говоря что подобные подходы, которые используете — перерос каждый участник сообщества. А ваш аргумент "я писал на Zend 1 и фреймы не нужны" — примерно как "я писал на PHP 4, по-этому считаю что PHP говно".
Слово «фреймворк» склоняется. Как и все остальные.
Сомнительная необходимость NAMESPACE
NAMESPACE это продолжение все той же истории, что и переменные в глобальной области видимости. Чтобы имена не пересеклись ввели NAMESPACE. Этого не надо было делать. Мое кошерное решение: композер на входе должен иметь PHP парсер кода и БД уникальных имен классов и интерфейсов, дирректорий внутри папки vendor. Фреймворк должен иметь приложение DEV, как есть в DEV.SKY. Есть зачаток такого приложения в Yii с генерацией файлов CRUD, в симфони только консольная утилита (этого мало). В приложении есть кнопка где можно сделать тоже самое — собрать уник. имена классов, чтобы они не пересеклись. Парсер PHP должен быть частью PHP, хороших реально-практически нужных задач для него много. Задача пересечения имен была бы решена на 100% более простым способом. Если вы скажете, что NAMESPACE дает много больше имен и в БД композера началась бы неразбериха, как подобная может быть при регистрации нового ник-нейма на популярном ресурсе, то я вам отвечу: вот именно это я называю помойкой. Я считаю, что должно быть так: один автор сделал класс и положил на композер. Другому класс понадобился он его скачал, но увидел что он плох. Модифицировал его, использовал в своем проекте, свое гениальное дополнение прокомментировал и положил на композер новую версию, добавился там автором.
Посмотрите что произошло с введением NAMESPACE: в институтах ввели новую лабораторную работу по NAMESPACE. Автор симфони и миллионы других занялись портированием своей работы в синтаксис с NAMESPACE. Это пустая трата времени. Код PHP стал менее прозрачный и медленее работать.
Надеюсь мое кошерное решение с NAMESPACE более значимо и прозрачно чем то что я пишу в глобальную область? Уберите огонь из души и настройтесь на чистый разум, может быть вы поймете, что мое решение хорошее? Я признаю, я был не готов отвечать по поводу моего писания в глобальную область. Я бы не хотел быть тем дядей Васей, который сказал писать туда можно, все меня послушали, а потом меня кто-то обвинил, что потерял очень много благодаря мне. А вы можете адекватно и честно оценить эту мою мысль?
На самом деле пропасть между именитыми умами и умом десятиклассника не так велика как кажется. Я приведу пример: разработчики PHP придумали magic quotes… Я думаю, что если я бы был в их команде, я бы сразу легко указал что это бред. Я их не обличаю, искренне думаю, наверно они это спьяну сотворили. Сейчас magic quotes отмирает, что вполне логично.
Другой пример: когда-то они будучи навеяны (были времена) трендом витающим в облаках который именуется «self described identifier» придумали $HTTP_GET_VARS, потом переименовали в $_GET и это хорошо. Это пример как витающие тренды вредят и нужно все воспринимать окружающих холодным рассудком.
Я почитаю Брайана Кернигана и Денниса Ритчи больше чем создателей PHP, хотя и их тоже. Надеюсь они не прочтут это и не будут обижены ). Создатели С это первый и самый большой «прорыв». В PHP массивы позволили писать как []. По этой же причине не нужно было вводить ключевое слово function. В языке низкого уровня С его нет, а в PHP (высокого) ввели… напрасно… Откройте любой файл на PHP и удалите слово function везде — он не станет менее читаем, в С же все ок. Вы представляете сколько трудо-часов в мировом масштабе тратятся на абсолютно бесполезные действия и одного из них набирать на клавиатуре слово function? По той же причине я бы еще много чего поменял в PHP, и фреймворках на PHP, но это отдельная тема… Трудно быть именитым…
И при определенных допущениях, по всем показателям лучше эквивалентного на симфони. Он прозрачен как на ладони, он быст и еще много чего. Там много кошерных классных решений.
а что если я вас скажу, что можно написать без строки стороннего кода и так, что у тех, кто будет читать ваш код, не будут литься кровавые слезы и не появится желания высверлить себе мозг перфоратором? Только для этого нужно немного попрактиковаться и почитать парочку книжек, тыкнуть какие-либо сторонние решения чтоб понять, зачем они так сделали.
Какие у вас там кошерные вещи зарыты в ядре? Пока что все ваши суждения похожи на «всю жизнь ел палочками, даже суп, ложки не нужны, не используйте ложки»
Сомнительная необходимость NAMESPACE
Мое кошерное решение: композер на входе должен иметь PHP парсер кода и БД уникальных имен классов и интерфейсов, дирректорий внутри папки vendor.— зачем?
Сейчас в современном php принята структура наименований классов — имя вендора/имя пакета/пространство имен пакета/название класса
Пример: Aura\SqlQuery\Mysql\Delete
Ваша идея — бессмысленна. Почитайте про psr-4 — что тут непрозрачного? Всегда понятно что и где находится.
Фреймворк должен иметь приложение DEV, как есть в DEV.SKY. Есть зачаток такого приложения в Yii с генерацией файлов CRUD
для симфони вы можете сделать так:
![](https://habrastorage.org/files/725/f09/e95/725f09e954c54f93b31bb42927ebce6a.png)
А для phalcon так — https://blog.phalconphp.com/post/dont-like-command-line-and-consoles-no-problem
Посмотрите что произошло с введением NAMESPACE: в институтах ввели новую лабораторную работу по NAMESPACE
беда то какая, придется потратить полчаса чтоб прочитать документацию и применить на практике
Код PHP стал менее прозрачный и медленее работать.
Сравните скорость работы php5.2 и php5.6, а лучше 7.0
Надеюсь мое кошерное решение с NAMESPACE более значимо и прозрачно чем то что я пишу в глобальную область? Уберите огонь из души и настройтесь на чистый разум, может быть вы поймете, что мое решение хорошее?
Нет, не хорошее.
Это пример как витающие тренды вредят
Что к примеру из таких трендов вредит? Возможность подключить в свой проект компоненты фреймвокров, библиотеки и все это ценой правки одного файла? Появление стандартов, которые облегчают понимание стороннего кода? Или то, что полностью весь код содержит phpdoc-секции, из которых понятно что и куда передавать и что получим на выходе?
Я считаю, что должно быть так: один автор сделал класс и положил на композер. Другому класс понадобился он его скачал, но увидел что он плох. Модифицировал его, использовал в своем проекте, свое гениальное дополнение прокомментировал и положил на композер новую версию, добавился там автором.
Ну а как сейчас происходит — вот собрал я для своего мелкого домашнего проектика некоторые библиотеки, и все хорошо, но не хватает мне какой-то фишки. Я делаю pull-request, его принимают и все пользуются новой фишкой быстро и безболезненно. Если же не принимают — юзаю свой форк с модификациями и радуюсь жизни, так же переподключая в следующие проекты.
Конечно, при условии что я как-то владею инструментом которым пользуюсь и понимаю что делаю. Если же у меня очень ограниченный запас знаний и практики — я запилю свое решение, в котором проигнорирую все лучшие практики и которым смогу пользоваться только я. А все потому, что без базовых знаний не применить все трендовые вещи, которые при понимании оказываются довольно простыми.
— зачем?
Сейчас в современном php принята структура наименований классов — имя вендора/имя пакета/пространство имен пакета/название класса
Пример: Aura\SqlQuery\Mysql\Delete
Ваша идея — бессмысленна. Почитайте про psr-4 — что тут непрозрачного? Всегда понятно что и где находится.
Это элементарно понять что я писал в данном случае не о прозрачности, а о избыточности функционала NAMESPACE.
Все… постараюсь больше не писать сюда ни комментов не статей.
На этом мой бенефис на хабре окончен. Всем спасибо.
Шаблон программирования CSN-Ajax