Comments 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) непонятно.
И за array_key_exists (несмотря на большую логичность, и @, и array_key_exists оказываются медленее isset).
Но вот зачем дублировать (и из isset, и из !empty уже́ следует array_key_exists) непонятно.
Както так ^_^
$ajax = strtolower(filter_input(INPUT_SERVER, 'HTTP_X_REQUESTED_WITH')) === 'xmlhttprequest';
вот именно… нужно сделать через ж., тогда будет в самый раз. Вот в этом вся соль современных популярных фреймворк. )
Захломить GET ненужным параметром, проверить, есть ли в GET этот параметр, сравнить значение этого параметра с нужным — это совсем не через ж..?) И при чем тут фреймворки?
Файлы coresky используют константу START в своем коде. От точки входа front или admin или cron или других зависит выполнение скрипта. Почему это константа START не нужна? Как можно иначе указать точку входа admin по вашему? Предложите лучше решение, чтобы «не захламлять GET»
При том, что вы по-видимому, почитатель их, как и все кто использует их в работе, а в них многое делается именно так, по моемУ мнению, поэтому появился мой фреймворк.
При том, что вы по-видимому, почитатель их, как и все кто использует их в работе, а в них многое делается именно так, по моемУ мнению, поэтому появился мой фреймворк.
Я только сейчас задумался. А что же в моем коде сделано через ж..?
В SKY Framework, для сайтов имеющих админ раздел есть такой стандартный код в index.php:
т. е. нужно еще установить константу START в `front ` или `admin` и раз уж этот код присутствует, то я считаю более предпочтительно не использовать ваш технологичный стандартный способ с HTTP_X_REQUESTED_WITH
Я не считаю панацеей стандарты, хотя, без них никак. На первом месте месте должна стоять комплексная оценка всех факторов важных для принятия решений. Люди выпускающие стандарты часто плохо работают. Пример? XMLHTTPRequest — к чему там слово XML? Если взять реальную жизнь: в ответах с сервера только в 5% имеется XML, в запросах еще меньше. Я имею ввиду реальные запросы на всех сайтах сейчас в Интернете. Это моя субъективная оценка, я могу ошибаться. В большинстве случаев передается на сервер application/x-www-form-urlencoded данные, а с сервера приходит либо HTML либо JSON, потому что работать с XML менее удобно. Ситуацию со стандартами надо прояснять, а не удручать.
Аналогично, любители все делать по стандарту, часто навязывают SOAP, там где в этом нет никакого смысла, хотя намного элегантнее было бы применить JSON кодирование.
<?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
Константа AJAX устанавливается не для любого ajax запроса, а для CSN-AJAX. Нужно быть уверенным что используется этот шаблон. Тогда можно быть уверенным, что ответ-ошибка (JSON с ключем catch_error), будет правильно обработан
А как насчет, чтобы показать ошибки backend? Я согласен что использовать HTTP_X_REQUESTED_WITH это технологично, но описываемая логика при этом не меняется.
И что же тут приятно? То что вы последовали стандарту и все? Ну последовали… какое преимущество получили? И почему вы назвали мой способ «костылем»? Он плохо работает или много лишнего кода? Или ваш способ более прозрачен для понимания новичку в программированию?
Я считаю что есть уровень HTTP и есть уровень приложения и с учетом константы START (читайте мой пост выше) предпочтительно на уровне приложения «гонять строку» ) Если бы не было необходимости в константе START я бы выбрал ваш способ. )
Спасибо за беседу.
Спасибо за беседу.
Спасибо за критику, но если критикуете, прошу приводить аргументы, а не отсылать на гугл. Почему вы решили что админка не нужна в фреймворке? Ваша логика?
А если SKY framework я назвал фреймворк, но у него есть средства для быстрого построения админки, вы совсем не знакомы с ним, но уверены что константы START не должно быть? Вы считаете что все должны быть похожи на симфони и ничего лучше придумать нельзя?
Мы кстати говорили не об админке-приложении, а о константе START только.
Мне никто не запрещал делать константу START в конце концов ) И называть мою работу SKY Framework ) Хотя признаю, в SKY Framework очень много сделано по своему и я даже согласен, что в некотором роде он что-то среднее между CMS и фреймворк в общественном понимании. Но у него возможности фреймворк по гибкости, по сравнению с CMS.
Мы кстати говорили не об админке-приложении, а о константе START только.
Мне никто не запрещал делать константу START в конце концов ) И называть мою работу SKY Framework ) Хотя признаю, в SKY Framework очень много сделано по своему и я даже согласен, что в некотором роде он что-то среднее между CMS и фреймворк в общественном понимании. Но у него возможности фреймворк по гибкости, по сравнению с CMS.
Если вы любитель симфони, то я знаю, что мне вас не переубедить (а вам меня), поэтому смысла нет продолжать беседу.
Спасибо!
Спасибо!
Это вы думаете, что вы тыкнули и что есть проблемы.
Ну и что вам не нравится?
Я не съезжаю, просто мы вдвоем только говорим, этого мало. Время жалко, впустую будет. Но в честь моей первой статьи на хабре — не пожалею время.
Ну и что вам не нравится?
Я не съезжаю, просто мы вдвоем только говорим, этого мало. Время жалко, впустую будет. Но в честь моей первой статьи на хабре — не пожалею время.
Лаконичность высказывания выше: 0. Наверно я должен был догадаться сам о чем это вы. Но я не догадался.
1. Если функция не нравится — пишите свою, она присутствует в коде 1 крыла, так как часто нужна, в PHP альтернативы нет. И меня устраивала до сих пор.
2. Я был бы рад провести публичное обсуждение каждой детали SKY, но в более дружелюбном тоне хотелось бы… Я уверен, что много вещей пришлось бы поправить. Сейчас это только лишь мой личный код.
3. Напишите как изменить ее чтобы стало верно?
4. Вы про фиксированную длину пароля? И про нач. установку генератора случ. чисел? Эта функцию удобно иметь в том виде, в каком она есть. Вы можете ее использовать в обертке и генерить пароли произвольной длины, а можете принудить юзера менять пароль после регистрации…
Нет… разговор в таком тоне, бесполезная трата времени.
1. Если функция не нравится — пишите свою, она присутствует в коде 1 крыла, так как часто нужна, в PHP альтернативы нет. И меня устраивала до сих пор.
2. Я был бы рад провести публичное обсуждение каждой детали SKY, но в более дружелюбном тоне хотелось бы… Я уверен, что много вещей пришлось бы поправить. Сейчас это только лишь мой личный код.
3. Напишите как изменить ее чтобы стало верно?
4. Вы про фиксированную длину пароля? И про нач. установку генератора случ. чисел? Эта функцию удобно иметь в том виде, в каком она есть. Вы можете ее использовать в обертке и генерить пароли произвольной длины, а можете принудить юзера менять пароль после регистрации…
Нет… разговор в таком тоне, бесполезная трата времени.
Вот именно, еще можно в .htaccess написать
deny from all
и третий способ поместить сис-файлы выше корня вебсервера. В SKY можно использовать хоть все 3, хотя по умолчанию сис-файлы в SKY приложении лежат в корне веб-сервера. Если вы считаете, что этот современный способ самый правильный, то почему? Не нужно ничего лишнего писать?
Но на чаше весов сложная структура папок.
Кроме того константа START содержит значение точки входа и от этого зависит работа файлов 1-2 крыла. Т.е. у нее двойное назначение, «убиваем 2 зайцев».
deny from all
и третий способ поместить сис-файлы выше корня вебсервера. В SKY можно использовать хоть все 3, хотя по умолчанию сис-файлы в SKY приложении лежат в корне веб-сервера. Если вы считаете, что этот современный способ самый правильный, то почему? Не нужно ничего лишнего писать?
Но на чаше весов сложная структура папок.
Кроме того константа START содержит значение точки входа и от этого зависит работа файлов 1-2 крыла. Т.е. у нее двойное назначение, «убиваем 2 зайцев».
Серьезно, сложная? создать папку publick переусложняет структуру? А не забыть везде проверить START — не сложно. А еще если я захочу код вендоров притянуть то как мне обезопасить их? А какие то внутренние вещи типа кэша или файлов с внутренней документацией и т. д. и т. п.
Вариант с ограничением по константе не просто устаревший, он несостоятельный.
Вариант с ограничением по константе не просто устаревший, он несостоятельный.
Вот поэтому есть стандартные файлы для админки, см. http://ru.coresky.net/code?admin/_main.php
В этом файле готовое решение — нажали на кнопку, скрипт пробежался и проверил.
Там кстати, есть сейчас только проверка на .htaccess и index.htm для стат.файлов — нужно будет добавить работу с START. Но раздел Guard есть.
В этом файле готовое решение — нажали на кнопку, скрипт пробежался и проверил.
Там кстати, есть сейчас только проверка на .htaccess и index.htm для стат.файлов — нужно будет добавить работу с START. Но раздел Guard есть.
Файлы с документацией вы на продакшн грузите? Я не
Так… и не забывайте, я выше написал: несложно реорганизовать структуру папок современным способом. Но я предпочитаю старый, несостоятельный как вы сказали.
Но вы ошибаетесь, он состоятельный, если сделать скрипт для этого.
Но вы ошибаетесь, он состоятельный, если сделать скрипт для этого.
Ну тогда еще раз. Как вы вашим «состоятельным» защитите вендорный код и всевозможные не php файлы?
Я сделал фреймворк, так как не мог найти подобного готового фреймворк. Это значит, что я в корне не воспринимаю современные подходы симфони, ларавел, Yii. В SKY совсем все по другому и такой папки как у вас vendors не будет вообще. Весь код хранится в codebase и управляется приложением DEV.SKY. Почитайте проект подробнее.
В SKY кардинально отличается подход во многом. Я уверен что laravel, symfony умрут как бейсик (ну ладно, фортран), это утопический путь для построения веб-приложений, нужно только время.
Мое мнение, что разработчики трендовых фреймворк, это дяди которые заигрались в игру, они делают чтобы «было красиво», но не слишком задумываются о истинной цели их работы. Они большие, дети.
Когда дело касается больших денег, никто не использует эти фреймворк, а пишут свой код.
В SKY кардинально отличается подход во многом. Я уверен что laravel, symfony умрут как бейсик (ну ладно, фортран), это утопический путь для построения веб-приложений, нужно только время.
Мое мнение, что разработчики трендовых фреймворк, это дяди которые заигрались в игру, они делают чтобы «было красиво», но не слишком задумываются о истинной цели их работы. Они большие, дети.
Когда дело касается больших денег, никто не использует эти фреймворк, а пишут свой код.
Чем же openssl_random_pseudo_bytes() лучше rand()?
Она напрямую не генерирует случайную строку того вида как в SKY функции.
Это: /dev/urandom
вообще, каким образом использовать, если разработка не в Unix?
В SKY все разрабатывается так, чтобы меньше зависеть от стороннего. Даже php.ini настраивать значение для часового пояса, менее удобно, чем просто в стандартной части админки, в готовом веб-интерфейсе выставить его значение (будет использоваться date_default_timezone_set())
Она напрямую не генерирует случайную строку того вида как в SKY функции.
Это: /dev/urandom
вообще, каким образом использовать, если разработка не в Unix?
В SKY все разрабатывается так, чтобы меньше зависеть от стороннего. Даже php.ini настраивать значение для часового пояса, менее удобно, чем просто в стандартной части админки, в готовом веб-интерфейсе выставить его значение (будет использоваться date_default_timezone_set())
я имел ввиду «если функция не подходит» — напишите свою
Кстати, код о котором мы говорили, это код приложения, а не фреймворк и недостоен столько внимания. Правда стандартный для обычных сайтов в Интернете, но для других приложений — нет. Вы не будете утверждать, что админ часть для сайтов в интернете это зло?
Вы гений инкапсуляции данных в объекты и неймспейсы? круто )
А как насчет недостатков вы их осознали? Если симфони так хорош, то почему появился ларавел? Или опереться на тренд, это все у вас?
Вы сами говорите, что переиспользовае кода (использование framework'а) это хорошо, так почему бы не переиспользовать уже существующий подход для определения типа запроса — HTTP_X_REQUESTED_WITH?
Большое вам спасибо! Вы только со статьей поспешили, завтра надо было выпускать. Но настроение подняли и даже не столько статьей, сколько шедевром «CoreSky.Net».
Спасибо вам что посмотрели
неужели у всего этого добра нашлись поклонники да еще и с возможностью минусить оО
Критика без аргументов похожа на лаение собак
Да какая тут может быть критика. Критика это когда "Хм интересно, но я не согласен по паре пунктов." У вас же всё плохо. Нет, серьезно, нет ни одного файла, функции, да практически строчки кода которые были бы нормальными.
Килотонны пафоса зато. Мне сначала было забавно, но чем больше тут от вас комментариев и тем мне страшнее. "Чувак, да что блин с тобой не так?"
Но давайте попробуем "покритиковать". Давайте не будем затрагивать что то уровня использования ООП, 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, то не зло это совсем.
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) Глобальные дефайны
Конечно, это всё утрирование и может для примера не особо подходит, но всё же… Я так писал, когда в школе учился (кроме шуток!).
1) А чем вам хуже глобальная область видимости в сравнении с любой другой?
В глобальной области видимости нет «всего скопом» там только view-переменные для стандартного layout — «main» который удобно поместить прямо в index.php. Что тут вам не нравится?
2) Мой вкус это SKY Framework )
3) не понял, что за «нативный fetch»?
4) Что плохого в том чтобы сделать небольшое количество констант через define? По-вашему PHP имеет возможность их делать, но их делать не нужно?
А вы «разутрируйте» ) Покритиковать легко без аргументов. Что вы плохого увидели кроме тривиально простого кода на вид?
Если просто, то это по вашему плохо?
В глобальной области видимости нет «всего скопом» там только 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?
1) если не готов дать ответ, то и писать не нужно
2) все когда-то начинали с нуля, но это не повод говорить, что код из-за этого плохой
3) вы любите сложности? это ваша проблема. Мне проще использовать $.post это короче писать и вполне достаточно для большинства ajax запросов.
4) я не понял… define( ) уже obsolete?
2) все когда-то начинали с нуля, но это не повод говорить, что код из-за этого плохой
3) вы любите сложности? это ваша проблема. Мне проще использовать $.post это короче писать и вполне достаточно для большинства ajax запросов.
4) я не понял… define( ) уже obsolete?
Новый фреймворк чаще всего создается, когда разработчик нового не приемлет многое в имеющихся. Сколько штук у нас их уже? В SKY Framework очень много не так, «как в тренде». Чтобы критиковать, надо приводить агрументы, а для этого надо тщательно изучить новое. А то что вам показалось, что вы так писали еще в школе оставлять при себе.
Главная идея — сделать минимальные дополнения к PHP чтобы он стал удобным для построения веб приложений. Вот в Get Started симфони тоже об этом пишут «голый PHP неудобен, сделаем симфони...». Но нужно ли было делать симфони, чтобы PHP стал удобен? Есть вариант сделать намного меньше и лучше.
Главная идея — сделать минимальные дополнения к PHP чтобы он стал удобным для построения веб приложений. Вот в Get Started симфони тоже об этом пишут «голый PHP неудобен, сделаем симфони...». Но нужно ли было делать симфони, чтобы PHP стал удобен? Есть вариант сделать намного меньше и лучше.
один из примеров зла в глобальных переменных это, как мне кажется, то что отлаживать такой код очень сложно ибо не известно в какой функции (методе класса) она изменилась и приходится с дебагом идти по всем вызовам.
Чую, получу несколько минусов. Но, называть фреймворком недоCMS, написанную по видеоурокам какого-нибудь Евгения Попова от 2007 года… Это ужас
Я даже не понимаю что отвечать таким людям. Сказать что это полное дерьмо — подумают что высокомерный мудак (простите), аргументировать как-то — через неделю появится новый человечек с очередным "убийцей вселенной". Понятное дело, что никто этим пользоваться не будет, но новички это всё читают и считают что это нормально. А после этого, см. коммент ниже — "Вот почему похапешников снисходительно-насмешливо называют похапешниками". И я полностью с этим согласен.
Вот почему похапешников снисходительно-насмешливо называют похапешниками, господа.
Подвожу итог — чего и следовало ожидать: аргументов о недостатках 0, только лишь агрессивное шкарябанье по клавиатуре и выпады. Это стандартно, все новое мы всегда воспринимаем в штыки, тем более от не авторитетного источника.
аргументов Вам написали уже достаточное количество.
Это не фреймворк. Это CMS
Кодстайл отсутствует.
Куча констант, глобальные переменные…
Писал много, но стер. Ибо говорить тут не о чем…
Это не фреймворк. Это CMS
Кодстайл отсутствует.
Куча констант, глобальные переменные…
Писал много, но стер. Ибо говорить тут не о чем…
Еще раз спрашиваю, чем глобальная область видимости хуже любой другой?
Всем. Вам, я думаю, не понять
Ну такого умного как вы, наверно да
Ну почему же он — я уже писал выше про отстрел себе ног из артиллерии, именно это и имея ввиду. Подразумевая, что это очевидно для каждого, но в ответ получил "если не готов дать ответ, то и писать не нужно".
После чего подумал, что продолжать не стоит. У человека (ну т.е. тебя) просто не достаточно опыта, чтобы это осознавать. Не то, что бы я или ваш оппонент выше были самыми умными на планете земля, но прошли достаточный путь развития, что бы смело дисктуровать на темы перспективности архитектуры и качества кода проекта. И я в этом уверен, раз человек упоминает хотя бы предметно-ориентированные подходы в разработке ПО.
Осталось только прислушаться, т.к. 99% (образно) начинали со своей супер-cms/игры/фреймворка/подчеркнуть-нужное.
на личности переходим?
Где то в своем скриптике тихо мирно выбрал я значит из бд пользователей в $users массив сложил. Потом надо мне их проитерировать, ну я и пишу foreach ($users as $user) И всё сломал ибо вы такой умный и у вас $user это глобал который хранит авторизованного пользователя.
Ок, вы умнее, забыли что там в index.php у simfony и сделали тоже самое с переменной $kernel… В чем разница?
Или вы думаете что вы будете итерить в глобальной области видимости обязательно? Есть в SKY Framework MVC — итерите в методе контроллера или модели
Или вы думаете что вы будете итерить в глобальной области видимости обязательно? Есть в SKY Framework MVC — итерите в методе контроллера или модели
Еще раз повторяю: в глобальной области SKY Framework нет того чтобы было «все скопом». Там малое кол-во переменных + main layout, который в index.php, там работает, потому что глобальная область видимости ничем не хуже других областей видимости.
В symfony $kernel не глобальная переменная. Там DI, DIC.
Хорошо, на сайте вы предлагаете скачать вот этот исходник для установки:
Заголовок спойлера
<?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+) Ну и так далее. Ошибки повторяются
Достаточно аргументов?
0) Undefined index: HTTP_HOST это проблема работы в разных ОС, у меня нет возможности сейчас тестировать код на разных ОС и разных веб серверах. Не могу
сейчас сказать почему у вас не заполнен ключ HTTP_HOST у меня такого никогда не было
4) проверка на то, что $_GET не пуcтой, проверки на существование вообще нет
О чем это вы? пустой массив приводится по типу к FALSE не пустой к TRUE.
Не в консоли он существует ВСЕГДА!
4) Сравнение нестрогие сравнения
А зачем лишний символ писать если он не нужен???
4) Относительные пути (при изменении рутовой диретории — оно вообще не будет работать)
Как раз будет! В SKY все приложения работает в поддиректориях вебсервера
11) Хедер редиректа? Почему просто не скачать?
Смысл такой: копируем dev.php из соседнего проекта (в соседней папке), он скачивает «свежий» установщик DEV.SKY. и вы работаете с новой версией DEV, в новом проекте в соседней папке. Для того, чтобы установить еще один DEV.SKY. вам не нужно ни на сайт идти, ни композер ни клон с гита. Это намного быстрее.
продолжу…
сейчас сказать почему у вас не заполнен ключ HTTP_HOST у меня такого никогда не было
4) проверка на то, что $_GET не пуcтой, проверки на существование вообще нет
О чем это вы? пустой массив приводится по типу к FALSE не пустой к TRUE.
Не в консоли он существует ВСЕГДА!
4) Сравнение нестрогие сравнения
А зачем лишний символ писать если он не нужен???
4) Относительные пути (при изменении рутовой диретории — оно вообще не будет работать)
Как раз будет! В SKY все приложения работает в поддиректориях вебсервера
11) Хедер редиректа? Почему просто не скачать?
Смысл такой: копируем dev.php из соседнего проекта (в соседней папке), он скачивает «свежий» установщик DEV.SKY. и вы работаете с новой версией DEV, в новом проекте в соседней папке. Для того, чтобы установить еще один DEV.SKY. вам не нужно ни на сайт идти, ни композер ни клон с гита. Это намного быстрее.
продолжу…
16) Никаких проверок нет, про автолоад не слышали
не понял про какие вы проверки? Про автолоад слышал вот доказательство:
http://ru.coresky.net/code?main/sky.php
см. метод SKY::autoload()
инициируется так: spl_autoload_register([$this, 'autoload']);
не понял про какие вы проверки? Про автолоад слышал вот доказательство:
http://ru.coresky.net/code?main/sky.php
см. метод SKY::autoload()
инициируется так: spl_autoload_register([$this, 'autoload']);
20) А если баз данных две?
Вы вообще-то смотрите приложение DEV.SKY. это не код фреймворк это готовое приложение и как хочу быть не может
Вы вообще-то смотрите приложение DEV.SKY. это не код фреймворк это готовое приложение и как хочу быть не может
0) Потому что я запустил скрипт через консоль, о чём я и написал
4) Я запустил из консоли
4) Ну наверное потому, что это лучше всегда. Но в данном случае не критично
4) Ну возможно, проверять опять не хочется, простите
11) Да ладно, наберите composer create-project — это всё, что нужно, чтобы поставить любой существующий современный фреймворк.
16) Тогда зачем реквайры?
20) А почему фреймворк зависит от БД? А что делать без БД? А как использовать лишь драйвер БД вашего "фрейма" без остального? А как запустить из под демона (реалтайм скрипт из консоли в памяти), а как...
А вы index.php от симфони тоже в консоле запускаете?
Вообще-то если видете $_GET то должно быть понятно что в браузере нужно )
Вообще-то если видете $_GET то должно быть понятно что в браузере нужно )
1) В симфони (ни сборке Standard, ни в фрейме) нет index.php
2) Там есть app/console для операций, включая установку всякого (подразумевается генерация кода)
3) Даже запуская app.php в консольке — вы не получите никаких ошибок, просто пустой объект реквеста
4) Установщик у симфони, как и любого современного фрейма — консольный. Просто потому, что фрейм не обязан зависеть от http и уж тем более браузера.
Т.е. вы говорите фреймворк для создания веб-приложений не обязан зависеть от браузера. А в SKY установщик зависит, насколько это плохо?
Ну конечно намного удобнее работать с приложением в консоле, а если браузер покажет все «на ладоне» то это плохо. Вы сами себе верите?
Нет все-таки приколько играть в игру «пусть будет красиво». Выдумываем какую-то абстрактную каноническую истину без особых оснований и следуем ей. Прекрасно.
Ну конечно намного удобнее работать с приложением в консоле, а если браузер покажет все «на ладоне» то это плохо. Вы сами себе верите?
Нет все-таки приколько играть в игру «пусть будет красиво». Выдумываем какую-то абстрактную каноническую истину без особых оснований и следуем ей. Прекрасно.
А в SKY установщик зависит, насколько это плохо?
Очень плохо. Это значит что на сервере его не стартануть. Представляете — на серверах одна консоль. Браузеров нет, вообще ничего нет, только открытый вовне порт на 80. А иногда и этого тоже нет и сервера тоже нет — скрипт лишь реализует отдачу отдачу данных, например в некоторых частях RTB систем. А ещё это может быть ботом, который мониторит что-нибудь, что-бы оно не упало и поднимает процессы и стоит отчёты. Или… Вариантов много и если нужно сделать веб-страничку — фреймворки нужны лишь когда проект сложный, а не уровня бложика на вордпрессе.
Вы изобрели высокосвязную CMS.
SKY Framework это код для повторного использования для создания веб-приложений. Чувствуете де-факто определение? И каким макаром он не обязан работать с браузером? Это раз.
Приложение DEV.SKY., файл dev.php, от которого вы смотрите, де-факто предназначено для работы только! на рабочей станции программиста (чтобы вы поняли, это альтернатива консольной утилите от симфони и веб-приложению! Yii для генерации CRUD шаблонов). Кстати в Yii надо сделать del ему по вашей логике тоже. Это два.
Читайте статью «Нужны ли сапожнику сапоги?» http://ru.coresky.net/blog?id42 это три.
Приложение DEV.SKY., файл dev.php, от которого вы смотрите, де-факто предназначено для работы только! на рабочей станции программиста (чтобы вы поняли, это альтернатива консольной утилите от симфони и веб-приложению! Yii для генерации CRUD шаблонов). Кстати в Yii надо сделать del ему по вашей логике тоже. Это два.
Читайте статью «Нужны ли сапожнику сапоги?» http://ru.coresky.net/blog?id42 это три.
Кстати, в симфони, есть отладочный модуль, который работает как веб-приложение, в режиме отладки, не помню как называется. Его по вашей логике нужно переделать в консоль?
Еще неплохо было бы все компьютерные игры портировать в консоль )
Ну вы сами себя слышите? Если есть разные опции… Есть возможность визуализировать процесс установки в браузере (это сапожник с сапогами), по вашему консоль удобнее? А как насчет установщика, например Drupal, который работает в браузере? Портировать в консоль? Вы скажете это не фреймворк, а приложение, у симфони шире область применения.
Ну прочтите определение для чего изобретен язык PHP — для работы с браузером, а то что он работает в консоле это дополнительная возможность, которая всегда идет номером два и не подразумевается что номера один нет.
И где же такие сервера, что PHP есть, а веб-сервера работающего на 80 порту нет?
Еще неплохо было бы все компьютерные игры портировать в консоль )
Ну вы сами себя слышите? Если есть разные опции… Есть возможность визуализировать процесс установки в браузере (это сапожник с сапогами), по вашему консоль удобнее? А как насчет установщика, например Drupal, который работает в браузере? Портировать в консоль? Вы скажете это не фреймворк, а приложение, у симфони шире область применения.
Ну прочтите определение для чего изобретен язык PHP — для работы с браузером, а то что он работает в консоле это дополнительная возможность, которая всегда идет номером два и не подразумевается что номера один нет.
И где же такие сервера, что PHP есть, а веб-сервера работающего на 80 порту нет?
Вам о чем то говорят слова CI, testing, deploy, phpunit?
Это тупиковая ветвь развития технологий для автора, скоро все это умрет аки бейсик.
А вообще пока мы тут пытаемся объяснить где автор не прав, он семимильными шагами приближается к кнопке «сделать пиздато», ой даже не кнопке, а к голосовой команде компьютер сделай сайт.
А вообще пока мы тут пытаемся объяснить где автор не прав, он семимильными шагами приближается к кнопке «сделать пиздато», ой даже не кнопке, а к голосовой команде компьютер сделай сайт.
а должны обязательно?
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 — фреймворк для тестирования
Удовлетворил знаниями?
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 — фреймворк для тестирования
Удовлетворил знаниями?
Это был тонкий намек на то, что, таки да, есть такие сервера, где есть php, но нет работающего веб-сервера.
К примеру есть этап тестирования, когда прогоняются тесты с помощью 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
К примеру есть этап тестирования, когда прогоняются тесты с помощью 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
До тестов пока дело не дошло, это сильно плохо, что я поспешил? Но планируется, только без phpunit. В SKY многие вещи кардинально отличаются от современного уже можно говорить «стандарта», поэтому без phpunit
Ну не нужен веб-сервер… это что панацея сделать так же? В SKY Framework всегда нужен, кроме консольных скриптов.
Ну не нужен веб-сервер… это что панацея сделать так же? В SKY Framework всегда нужен, кроме консольных скриптов.
Ну и вы считаете следует обвязать дополнительно кодом dev.php чтобы не было ошибок в консоле. А я предпочитаю не обвязывать, а посмотреть в скрипт и увидеть что он не консольный и запустить его как полагается.
Это философский вопрос — как лучше. Выше мне минусов наставили за то что @скрытие_ошибок медленно работает, а навязать ненужный код, это правильно.
Это философский вопрос — как лучше. Выше мне минусов наставили за то что @скрытие_ошибок медленно работает, а навязать ненужный код, это правильно.
А почему фреймворк зависит от БД?
не зависит.
А что делать без БД?
Веб приложений без БД не бывает сейчас. Вы вообще хоть немного вникли в SKY? coresky это всего лишь 3 файла объемом 54 килобайта
не зависит.
А что делать без БД?
Веб приложений без БД не бывает сейчас. Вы вообще хоть немного вникли в SKY? coresky это всего лишь 3 файла объемом 54 килобайта
нашел в инете:
Change HTTP_HOST to SERVER_NAME to prevent problems with client not setting HTTP_HOST
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 и иже с ним
Окай…
1. Гашение ошибок… Ошибки нужно не гасить, а устранять.
2. Глобальные переменные — плохой подход. И это не я утверждаю.
3. Определять что-то константами, и тем более проверять константы в файлах класса… Это в 2000 году было нормой
4. Кодстайл… Почитайте PSR
5. Я не увидел там никакого MVC. Пародию увидел
6. Спагетти-код
7. Глобальные переменные везде. Я про $_GET и иже с ним
1. Ошибки нужно не гасить, а устранять.
Это кто сказал? Почему все обязаны вам верить? По-видимому здесь на хабре пришли к такой мысли все… И это авторитетное мнение… Я не делал тестирование скорости работы @ если реально сильно медленное — можно в будущем устранить, а лучше пофиксить PHP, чтобы работало быстро. Если это рекомендация никогда не применять @ ввиду возможной запарки и создания себе сложной жизни и невозможности локализовать ошибку, — то это вопрос философский… Я ставлю подавление ошибок ТОЛЬКО в тех местах, где явно не будет проблем с локализацией ошибок, аналогично использую eval( ).
То что де-факто считается зло в сообществе людей с взглядом как у вас, дает ощутимые преимущества в краткости и простоте кода.
Я понимаю, что «много на себя беру» ставя под сомнение то, что eval и @ зло, как считается в вашем привычном кругу. Но на первом месте у меня не следование общепринятым нормам, а открытая логика. Я считаю, что если программист не может применить @ или eval( ) безошибочно, чтобы не сделать себе зло, то он и так не будет способен программировать, «делать вещи».
Реальное зло — оператор GOTO доказано математически и выброшено из всех языков программирования, eval же везде есть, так что это сомнительное зло.
Это кто сказал? Почему все обязаны вам верить? По-видимому здесь на хабре пришли к такой мысли все… И это авторитетное мнение… Я не делал тестирование скорости работы @ если реально сильно медленное — можно в будущем устранить, а лучше пофиксить PHP, чтобы работало быстро. Если это рекомендация никогда не применять @ ввиду возможной запарки и создания себе сложной жизни и невозможности локализовать ошибку, — то это вопрос философский… Я ставлю подавление ошибок ТОЛЬКО в тех местах, где явно не будет проблем с локализацией ошибок, аналогично использую eval( ).
То что де-факто считается зло в сообществе людей с взглядом как у вас, дает ощутимые преимущества в краткости и простоте кода.
Я понимаю, что «много на себя беру» ставя под сомнение то, что eval и @ зло, как считается в вашем привычном кругу. Но на первом месте у меня не следование общепринятым нормам, а открытая логика. Я считаю, что если программист не может применить @ или eval( ) безошибочно, чтобы не сделать себе зло, то он и так не будет способен программировать, «делать вещи».
Реальное зло — оператор GOTO доказано математически и выброшено из всех языков программирования, eval же везде есть, так что это сомнительное зло.
Проблема с Eval'om всегда одна и та же. В неё все равно кто то протащит исполняемый, но не по назначению код.
А собака(@) это как газетку на говно постелить. То есть его не видно. Но воняет и остальные не поймут почему.
Как можно в eval «протащить» вирус, если код «под eval» конструируется другим кодом PHP который никак не связан с данными в БД? В index.php у меня есть eval(SKY_FRONT::PROC);
::PROC это вообще константа. Используется eval чтобы сократить код в index.php сделать его простым. ::PROC это стандартный константный код который нужен для построения сайтов.
<? eval($sky) ?> $sky это объект, тут используется __toString магический метод, чтобы вытянуть $sky->code, который генерируется таким образом, что там не может никак оказаться произвольный код, так как опять таки он состовляется из разных константных кусочков строк. Каждое $sky->code .=… вот такое добавление проанализировано мной на предмет того, что случайного кода быть не может.
::PROC это вообще константа. Используется eval чтобы сократить код в index.php сделать его простым. ::PROC это стандартный константный код который нужен для построения сайтов.
<? eval($sky) ?> $sky это объект, тут используется __toString магический метод, чтобы вытянуть $sky->code, который генерируется таким образом, что там не может никак оказаться произвольный код, так как опять таки он состовляется из разных константных кусочков строк. Каждое $sky->code .=… вот такое добавление проанализировано мной на предмет того, что случайного кода быть не может.
Да там евалов просто море. Вон и модуль пагинации, который по моему не все реплейсит.
А еще там есть лютейший extract без EXTR_SKIP.
Который может вообще пустить по банану и перезаписать любую переменную, которая потом так же прилетит в require или eval. Но я не смог это проверить, ибо ваша поделка не запускается на PHP 7. Совсем.
а EXTR_SKIP обязательно всегда ставить? не знал. напишите разработчикам PHP — пусть намертво пофиксят.
Насчет PHP 7 — это серьезный прокол, не тестил. Обещаю в ближайшее время исправить. В этом проекте это задача номер 1. Если ничего не случится с моим свободным временем исправлю быстро. Но прошу вас меня понять: несмотря на то что coresky это 3 файла всего лишь размером 45 кБ, работы в проекте чрезвычайно много, а помощников у меня мало.
Насчет PHP 7 — это серьезный прокол, не тестил. Обещаю в ближайшее время исправить. В этом проекте это задача номер 1. Если ничего не случится с моим свободным временем исправлю быстро. Но прошу вас меня понять: несмотря на то что coresky это 3 файла всего лишь размером 45 кБ, работы в проекте чрезвычайно много, а помощников у меня мало.
«помощников у меня мало.» — это сколько?
может вам еще ключ от квартиры? ) вам это знать не обязательно. Достаточно, что я сказал «мало». Иначе конечно обертка была бы красивее
Пожалуй откажусь от такого предложения.
Можно спросить в каких реальных проектах используется данная система?
Видео на главной странице не впечатляет, блог проще создать установив вордпресс. Результат будет более юзабильным, а время запуска блога будет таким же
Можно спросить в каких реальных проектах используется данная система?
Видео на главной странице не впечатляет, блог проще создать установив вордпресс. Результат будет более юзабильным, а время запуска блога будет таким же
отпустите своих помощников пока не поздно, дайте им шанс…
Это вменяемый функционал и нужный. Зачем его фиксить, он работает как надо. Это вы используете его не правильно.
Я умываю руки)
«Зачем покупать новую машину, если есть Москвич 73 года выпуска. Он же работает. Ну и путь он троит, дымит, чихает, зато едет. Тушку мою перевозит и ладно. А те, кто критикует — просто ничего не понимают. Ну и пусть нет запчастей. Я возьму деталь от трактора, подточу на наждаке и загоню молотком. А чтобы не отвалилось — надежно приклею скотчем»
«Зачем покупать новую машину, если есть Москвич 73 года выпуска. Он же работает. Ну и путь он троит, дымит, чихает, зато едет. Тушку мою перевозит и ладно. А те, кто критикует — просто ничего не понимают. Ну и пусть нет запчастей. Я возьму деталь от трактора, подточу на наждаке и загоню молотком. А чтобы не отвалилось — надежно приклею скотчем»
2. Глобальные переменные
Вы путаете грешное с праведным. В том «что не вы утверждаете» имелось ввиду «не вносить в глобальную область видимости переменные разного функционала», так как опять таки сложно будет локализовать ошибки, да и не верно это просто логически. Так нет у меня «всего скопом». Пятый раз пишу… Чем глобальная область видимости хуже метода класса, в которой, в вашем фреймворк расположен код LAYOUT. А в SKY LAYOUT расположен в глобальной, и что тут не так?
Вы путаете грешное с праведным. В том «что не вы утверждаете» имелось ввиду «не вносить в глобальную область видимости переменные разного функционала», так как опять таки сложно будет локализовать ошибки, да и не верно это просто логически. Так нет у меня «всего скопом». Пятый раз пишу… Чем глобальная область видимости хуже метода класса, в которой, в вашем фреймворк расположен код LAYOUT. А в SKY LAYOUT расположен в глобальной, и что тут не так?
3. Определять что-то константами, и тем более проверять константы в файлах класса… Это в 2000 году было нормой
Иногда новое это хорошо забытое старое. А я считаю, что у нынешних трендов нет будущего. Потому как забрели «далеко в лес» играясь с разными вещами без оснований.
Иногда новое это хорошо забытое старое. А я считаю, что у нынешних трендов нет будущего. Потому как забрели «далеко в лес» играясь с разными вещами без оснований.
Думал, зайду, прочитаю что-то интересное, свежее, заголовок-то какой. А на деле? От статьи, а уж тем более от Ваших комментариев, просто волосы дыбом встают и глаза округляются. И, чем дальше читаешь, тем меньше каких-то внятных аргументов остается, так как понимаешь, что доказать что-то вряд ли получится.
Единственное, что позволю себе заметить:
Ну, правда, все-таки 2016 год на дворе.
Единственное, что позволю себе заметить:
Новый фреймворк чаще всего создается, когда разработчик нового не приемлет многое в имеющихся.Не «когда он не приемлет» чего-то, а когда ему не даются существующие технологии и обкатанные стандарты, и ему не понятно, по той или иной причине, зачем были сделаны те или иные вещи, и что сделаны они были далеко не глупыми инженерами. Вот тогда и появляются новые движки, библиотеки и фреймворки, решаюшие уже решенные проблемы и собирающие уже давно пофикшенные баги.
Ну, правда, все-таки 2016 год на дворе.
Автор, объясните, пожалуйста, как и где в Вашем фреймворке реализовывается паттерн MVC?
Лично я этого не обнаружил
Лично я этого не обнаружил
Добавил в избранное только ради того, чтоб не потерять этот «шедевр».
Оффтоп. Вы забыли про важное выражение «принципиально новый»!
Оффтоп. Вы забыли про важное выражение «принципиально новый»!
Больше похоже на какой-то безумный троллинг хабровчан.
G-M-A-X, перелогиньтесь.
main/sky.php, Class Sky но почему у методов не объявлена видимость. Где док.блоки.
mysql_* Deprecated
PHP 7 — вообще не запустилось ничего.
Дальше даже проверить не смог.
почему у методов не объявлена видимость?
А вы не в курсе? если не объявлена, — значит public
А вы не в курсе? если не объявлена, — значит public
Блин я умираю с каждого вашего комментария)))
Спасибо за веселую пятницу. С коллегами позабыли о работе, разговоры только о новом фреймворке и его уникальном авторе)))
В общем доказывать вам что-либо нет смысла. Все доводы и критику Вы воспринимаете в штыки, типа:
«Эй, поц, есть телефон позвонить? А если найду?»
Вы не задумывались о том, почему фортран умер?
Да ровно по тому же, почему не производят Москвичей 73 года
Ровно по тому, почему умерли ламповые телевизоры, компакт-кассеты и прочие пережитки былых эпох.
Вы же со своим кодом остались в тех временах, когда было нормой defined('SITE_NAME') or die('Direct access');
Ну что же. Нам остается только пожелать Вам удачи во всех Ваших начинаниях и продолжениях.
ЗЫ. Уж очень хочется глянуть в то время, когда современные технологии программирования умрут, как фортран)))
Спасибо за веселую пятницу. С коллегами позабыли о работе, разговоры только о новом фреймворке и его уникальном авторе)))
В общем доказывать вам что-либо нет смысла. Все доводы и критику Вы воспринимаете в штыки, типа:
«Эй, поц, есть телефон позвонить? А если найду?»
Вы не задумывались о том, почему фортран умер?
Да ровно по тому же, почему не производят Москвичей 73 года
Ровно по тому, почему умерли ламповые телевизоры, компакт-кассеты и прочие пережитки былых эпох.
Вы же со своим кодом остались в тех временах, когда было нормой defined('SITE_NAME') or die('Direct access');
Ну что же. Нам остается только пожелать Вам удачи во всех Ваших начинаниях и продолжениях.
ЗЫ. Уж очень хочется глянуть в то время, когда современные технологии программирования умрут, как фортран)))
Да почему же в штыки? Я нормально отвечаю, спрашиваю ). Хм, извините еще раз если вам так показалось. Тогда скажите, как вы среагируете на насмешливую критику, где вместо логичных доказательств идет просто опор на бренды и закостенелое мнение о вещах. А логика не учитывается.
Как я должен реагировать на ваши насмешливые посты? Как вы реагируете если бы оказались на моем месте? Если уличение от авторитетного источника — то понятно, и я так же. А если не от авторитетного? Разве я не толерантный? )
Вы меня простите, но я вас не знаю и вы мне не авторитет. Даже более того, я почти уверен что не авторитет. Авторитет для меня не тратил бы время на то, что тратите вы здесь. Это номер 1 и этого достаточно.
Как я должен реагировать на ваши насмешливые посты? Как вы реагируете если бы оказались на моем месте? Если уличение от авторитетного источника — то понятно, и я так же. А если не от авторитетного? Разве я не толерантный? )
Вы меня простите, но я вас не знаю и вы мне не авторитет. Даже более того, я почти уверен что не авторитет. Авторитет для меня не тратил бы время на то, что тратите вы здесь. Это номер 1 и этого достаточно.
Есть такая книженция, сам с нее начинал, крайне рекомендую к прочтению: С.Макконнелл «Совершенный Код». Если уж для Вас и товарищ Стив не авторитет, то тогда я уже и не знаю, что добавить.
Объясните мне простую вещь: почему нельзя писать переменные в глоб. область видимости. Пусть в абстрактном языке. Если вы это сделаете — вы будете моим авторитетом. Мной овладеет глубокая печаль (кроме шуток) и я стану печально думать что делать с моей работой. Я не шучу!
Если ваш ответ: в глоб. области образуется помойка. Но сразу другой вопрос: а если в глоб. области переменные одного лишь функционала! Чем хуже она области видимости внутри метода класса??
Только прошу — логику. Ничего кроме нее. Ответ нельзя потому что все так говорят — не подходит.
Если ваш ответ: в глоб. области образуется помойка. Но сразу другой вопрос: а если в глоб. области переменные одного лишь функционала! Чем хуже она области видимости внутри метода класса??
Только прошу — логику. Ничего кроме нее. Ответ нельзя потому что все так говорят — не подходит.
Тем, что внутрь метода класса к Вам сбоку абстрактный дядя Вася не сможет залезть и «нагадить», переопределив что-нибудь. Ваш код становится защищен от среды его выполнения, он не хрупок и предсказуем. Чего не скажешь о глобальной области видимости, где не только Вам могут поломать код, но и, что страшнее для Вас как создателя движка, Вы можете сломать чьи-то чужие глобальные переменные. Изоляция — это, уж извините, много много лет как best-practise. Подробно описано в книге, упомянутой комментарием выше.
Переменные в глобальной области видимости плохо, потому что если с вашим кодом будут работать другие люди, они могут в своем коде переопределить ваши переменные и вся ваша конструкция сломается.
Типичный пример на сайте используется js библиотека prototype, клиент просит поставить виджет его партнера, в виджете используется jquery. Производитель виджета не позаботился о безопасном использовании библиотеки jquery и код сайта ломается после загрузки виджета.
Это раз.
Разработчик который будет работать с вашим кодом должен ознакомиться со всей лапшой кода вашего ядра и найти все эти глобальные, чтобы найти почему код поломался. Ну или заранее чтобы не прострелить себе ногу.
Магические цифры в коде приложения, допустим разработчик не открывал файл с этими цифрами год, такое часто случается. А потом открывает и видит -23, 96, 15 передаваемые в параметры функций. Что это за цифры? Почему -23, а не -26?
Типичный пример на сайте используется js библиотека prototype, клиент просит поставить виджет его партнера, в виджете используется jquery. Производитель виджета не позаботился о безопасном использовании библиотеки jquery и код сайта ломается после загрузки виджета.
Это раз.
Разработчик который будет работать с вашим кодом должен ознакомиться со всей лапшой кода вашего ядра и найти все эти глобальные, чтобы найти почему код поломался. Ну или заранее чтобы не прострелить себе ногу.
Магические цифры в коде приложения, допустим разработчик не открывал файл с этими цифрами год, такое часто случается. А потом открывает и видит -23, 96, 15 передаваемые в параметры функций. Что это за цифры? Почему -23, а не -26?
Вы невнимательно прочитали условие задания которое я написал. В глобальной области видимости «нет помойки» там один прозрачный функционал.
Совершенно аналогично вы можете в методе объекта создать лок. переменную, а потом забыть о ней и переопределить.
В SKY Framework с MVC паттерном, код приложения полностью размещается в методах класса и пользователь глобальную область не трогает. Кроме переменных в файле VIEW т.е. в main layout но они все с префиксами.
Еще аргумент: coresky это 45 кБ кода, подразумевается, что разработчик SKY полностью им владеет.
Практика: я несколько лет делаю сайты на SKY Framework — никаких проблем описываемых вами нет абсолютно. Справедливости ради скажу, более 10 лет назад, подобные проблемы были, но они несложно решались. И не так страшен рак как его малюют.
Я понимал, еще давно, что работая в глобальной области видимости я делаю лишний повод покритиковать себя. Но тривиальная простота кода и прозрачность перевесила в моем решении использовать такой подход.
Совершенно аналогично вы можете в методе объекта создать лок. переменную, а потом забыть о ней и переопределить.
В 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 лет проектируете, в авторитеты к вам я не стремлюсь. Более того, уверен, что к понедельнику я про эту тему уже и не вспомню.
У вас своя правда, вот только чужое мнение вам не интересно.
Доказывать вам тут ничего я не собираюсь. Опять же, ваше дело. Как хотите так и пишите.
Но… «Есть же какие-то вещи» (с) Шуренберг
Конечно, мне ваше мнение интересно. Иначе зачем бы я делал сайт в том виде в каком он есть? Это проект для программистов.
Я знал давно, многие вещи о которых вы говорите, о глобальной области и т.д. и сознательно их нарушил. Я хотел, чтобы вы посмотрели, чего можно достичь если нарушить их. А вы просто шлепнули меня ими. А чтобы увидеть чего можно достичь нужно более внимательно присмотреться к проекту, а не «одним глазом».
Посмотрите в историю: незыблемые стены тоже иногда рушатся, просто на все нужно свое время. А новое это часто хорошо забытое старое.
Я знал давно, многие вещи о которых вы говорите, о глобальной области и т.д. и сознательно их нарушил. Я хотел, чтобы вы посмотрели, чего можно достичь если нарушить их. А вы просто шлепнули меня ими. А чтобы увидеть чего можно достичь нужно более внимательно присмотреться к проекту, а не «одним глазом».
Посмотрите в историю: незыблемые стены тоже иногда рушатся, просто на все нужно свое время. А новое это часто хорошо забытое старое.
Волевым решением сообщество решило не писать в глобальную область видимости. Но это одно из тех решений когда оно есть палка о двух концах. Решив одну проблему, оказалось что нужно писать больше кода и он стал сложнее для восприятия, думаю что также код стал более медленный (3 минуса)
Если выбрать другое решение — эти минусы стали плюсами. А граблей, которыми все пугают, пока не встречал, если все сделать аккуратно.
Если выбрать другое решение — эти минусы стали плюсами. А граблей, которыми все пугают, пока не встречал, если все сделать аккуратно.
Это проект для программистов
Интересно. Когда спадет хабраэффект, насколько упадет количество скачиваний Вашего проекта)
А вы не в курсе что не хорошо не договаривать. Сказал function — говори и видимость
Обожаю подобные посты про самописные cms и фреймворки. Особенно когда автор положил огромный болт на какие-либо правила и общеизвестные приемы и всерьез считает что именно его решение кошерно, а все остальные могут лососнуть тунца.
А причина простая — вместо того, чтоб изучить инструмент, с которым работаешь (в данном случае php), люди бросаются писать решение под себя, потому что порог вхождения невысок и позволяет получить результат быстро, пусть и кривыми способами, а известные решения кажутся слишком сложными из-за непонимания базовых принципов. Ну а после — так и используют свое решение, не пытаясь даже смотреть в сторону других, с большим сообществом, оттестированных и проверенных временем.
Если автор не тролль, что маловероятно, то пусть почитает:
http://getjump.me/ru-php-the-right-way/
https://getcomposer.org/
http://www.php-fig.org/psr/
А причина простая — вместо того, чтоб изучить инструмент, с которым работаешь (в данном случае 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.
Или я не верно понял ваш комент...
Верно поняли. Я имел ввиду, что мою работу нужно корректировать. Знал и о композере и PHP FIG и глоб. области и о eval и что получу подобную реакцию здесь. Но не знал, что она повлияет на меня так. Это не значит, что я буду работать с симфони или подобным фреймворком. Ну не приемлет у меня душа этот современный подход… Буду искать альтернативные решения наверно, например, в сторону анализаторов кода, чтобы результат был не хуже чем: не пишем в глобальную область — значит 100% не получим ошибки такого типа, анализировать теорию и практику, между ними бывает пропасть.
По моему мнению слишком большой ценой (увеличением, осложнением, меньшей производительностью, меньшей прозрачностью кода) мы со 100% вероятностью всего лишь гарантированно не получим ошибки одного типа. Это муха против бомбы можно сказать. Но я понимаю, что это может оказаться очень серьезно в самый неподходящий момент… В общем я в размышлениях пока что.
Обязательно хочу прочитать и сравнить свои мысли с первоисточником по поводу глоб. области, eval и @подавлении ошибок. Просто принять без осмысления наверно не смогу. В общем, мне сложно описать, что я чувствую сейчас и какой выберу путь, но спасибо вам за общение, оно было не зря однозначно. Если рассмешил — на здоровье, если отнял время — sorry.
По моему мнению слишком большой ценой (увеличением, осложнением, меньшей производительностью, меньшей прозрачностью кода) мы со 100% вероятностью всего лишь гарантированно не получим ошибки одного типа. Это муха против бомбы можно сказать. Но я понимаю, что это может оказаться очень серьезно в самый неподходящий момент… В общем я в размышлениях пока что.
Обязательно хочу прочитать и сравнить свои мысли с первоисточником по поводу глоб. области, eval и @подавлении ошибок. Просто принять без осмысления наверно не смогу. В общем, мне сложно описать, что я чувствую сейчас и какой выберу путь, но спасибо вам за общение, оно было не зря однозначно. Если рассмешил — на здоровье, если отнял время — sorry.
Буду искать альтернативные решения наверно, например, в сторону анализаторов кода
Локально: https://plugins.jetbrains.com/plugin/7622?pr=idea
Удалённо: https://scrutinizer-ci.com/
Мне кажется, Вы, как сравнительно новичёк, верно чувствуете многие недостатки PHP (в отличие от тех, кто копается в нём уже давно и «за деревьями не видит леса»; вот взять, например, MetaDone, которых пишет «а известные решения кажутся слишком сложными из-за непонимания базовых принципов» — бред же, известные решения кажутся слишком сложными из-за того, что они слишком сложны; реакция новичка при вхождении в язык — это отличный индикатор продуманности языка; в отличие от сениора, который уже просто привык и глаз замылился).
Но устраивать «революцию» Вам ещё ого-го как рано. То, что Вы предлагаете — для большинства use-case'ов — не лучше существующих решений, которые Вы критикуете (хотя в каких-то use-case'ах может в чём-то оказаться и лучше, не спорю). И большинству людей Ваш фреймворк не нужен (даже дописанным и отлаженным). В лучшем случае, Вы настрогаете на этом фреймфорке пару-тройку сайтов и приобретёте опыт. Но чтобы идти в массы с ним — зась (и не потому что сам фреймворк сырой и недописанный, а потому что Ваше понимание проблем и видение их решений ещё далеко до созревания).
У Вас (кажется, могу ошибаться) есть ум и самоуверенность. Это хорошо; эти два качества редко бывают вместо (часто умные люди неуверены и наоборот). Но то, что Вы предлагаете пока, очень сырое.
Но устраивать «революцию» Вам ещё ого-го как рано. То, что Вы предлагаете — для большинства use-case'ов — не лучше существующих решений, которые Вы критикуете (хотя в каких-то use-case'ах может в чём-то оказаться и лучше, не спорю). И большинству людей Ваш фреймворк не нужен (даже дописанным и отлаженным). В лучшем случае, Вы настрогаете на этом фреймфорке пару-тройку сайтов и приобретёте опыт. Но чтобы идти в массы с ним — зась (и не потому что сам фреймворк сырой и недописанный, а потому что Ваше понимание проблем и видение их решений ещё далеко до созревания).
У Вас (кажется, могу ошибаться) есть ум и самоуверенность. Это хорошо; эти два качества редко бывают вместо (часто умные люди неуверены и наоборот). Но то, что Вы предлагаете пока, очень сырое.
бред же, известные решения кажутся слишком сложными из-за того, что они слишком сложны;
Не решения сложны, а порог входа в php не очень высокий. Можно сделать как в старые темные времена прям в странице sql-запрос и вывод в браузер и это будет работать. Просто же. А вот чтоб понимать чем такие действия грозят и как трудно это потом поддерживать будет — нужно чуток знать как в целом все работает. Потому поначалу и кажется, что шаблонизаторы, контейнеры зависимостей, orm и т.п. — лишние звенья. Зачем они нужны, если в конце все равно пользователь получил страницу?
Как раз решения сложны.
Если новичку проще втюхать SQL-запрос (вдумайтесь — SQL-запрос!), чем заюзать ORM — значит интерфейс ORM сложнее, чем должен быть; точка; другое дело, что PHP, возможно, не позволяет реализовать ORM с более простым API (автор ORM уже сделал всё, что мог, и это не его вина, что проще не получилось).
Новички юзают уродливые способы не из какого-то там принципа; а просто потому, что способы, которые решают задачу более правильно, имеют более сложное API, чем уродливые; вот и всё.
Если новичку проще втюхать SQL-запрос (вдумайтесь — SQL-запрос!), чем заюзать ORM — значит интерфейс ORM сложнее, чем должен быть; точка; другое дело, что PHP, возможно, не позволяет реализовать ORM с более простым API (автор ORM уже сделал всё, что мог, и это не его вина, что проще не получилось).
Новички юзают уродливые способы не из какого-то там принципа; а просто потому, что способы, которые решают задачу более правильно, имеют более сложное API, чем уродливые; вот и всё.
Новички юзают уродливые способы не из какого-то там принципа; а просто потому, что способы, которые решают задачу более правильно, имеют более сложное API, чем уродливые; вот и всё.
и чем это отличается от моего высказывания — «известные решения кажутся слишком сложными из-за непонимания базовых принципов»?
Тем, что корень проблемы не в непонимании базовых принципов, а в переусложнённости существующих реализаций, которые решают задачу «правильно».
Часть «принципов», стоящих на пути к правильному решению, являются более-менее интуитивно понятными и осваиваются на лету.
Часть «принципов» вообще не имеют отношения к решению задачи, а возникают из-за того, что автор библиотеки перемудрил (это необязательно его вина; он мог делать как мог просто в условиях данного языка/платформы; т.е. что в условиях данного языка/платформы задача не решается просто и правильно одновременно; но для новичка это лишняя нагрузка).
Часть «принципов», стоящих на пути к правильному решению, являются более-менее интуитивно понятными и осваиваются на лету.
Часть «принципов» вообще не имеют отношения к решению задачи, а возникают из-за того, что автор библиотеки перемудрил (это необязательно его вина; он мог делать как мог просто в условиях данного языка/платформы; т.е. что в условиях данного языка/платформы задача не решается просто и правильно одновременно; но для новичка это лишняя нагрузка).
как раз в непонимании базовых принципов и есть проблема. Без умения читать печатать на клавиатуре не получится. Так и тут — люди освоили синтаксис чтоб средствами php получить что-то из базы — все, золотой молоток найден, будем склеивать строки и радоваться. Вывели это на страницу — ну да ладно, пусть ругается что заголовки уже отправлены, главное работает. И получаются на выходе нежизнеспособные уродливые гомункулы, чью красоту оценить может только их создатель. А популярные решения идут лесом, потому что нужно помнить про всякий «мусор» — тестирование, консольные команды, сущности, репозитории, сервисы, шаблонизаторы и т.п… Зачем забивать голову чем-то еще, если это работает?
Проблема не в том, что сложны решения, а в том что в сложности нет необходимости. Я работал с Zend.1 больше года, в очень крупной компании. Мои веб-приложения в продакшн прекрасно работают. Мой общий опыт в программировании более 20 лет, в PHP — 12 лет. Проблема в том, что мне хотелось постоянно материться, когда я работал с Zend из-за неверных, по моему мнению, решений в фреймворк. Из списка «ваших трендовых фреймворк» это все, но я считаю этого достаточно, чтобы говорить о том, что я имею о них представление.
Базовые принципы «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» рубит сук на котором сидит — нещадно увеличивает сложность.
Базовые принципы «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» рубит сук на котором сидит — нещадно увеличивает сложность.
Имхо разумный уровень гибкости покрытие 70% сайтов в интернете. Какой разумный по-вашему уровень гибкости? Параноидально гибкий (максимально) это хорошо? Читайте о clear cloud и cloud modification на сайте
http://ru.coresky.net/roots?id26
http://ru.coresky.net/roots?id33
http://ru.coresky.net/roots?id26
http://ru.coresky.net/roots?id33
подход «right way» очень много стоит (потери). Нужно только хорошо посчитать.
Вы сталкивались с проблемой: чтобы просто «чихнуть» в PHP вам нужны пара-тройка классов. Я сталкивался в Zend, и предпочел бы иное.
В моем понимании «full stack framework» — это значит, нужно мне например везде array() заменить на [] и пару раз кликнул в приложении DEV и сделал это. Существует несколько десятков таких типов задач, которые должен легко решать «full stack framework». DEV должен быть всегда под рукой. Не нужно лезть в БД композера искать классы и мастерить скрипт для такой замены на [], это долго. Может этот пример не слишком убедительный в плане необходимости DEV, но работа с таблицей _lang более убедительна (ищите на моем сайте), а также смотрите иной функционал
«right way» имхо, выдвинуло некоторые теоретические догмы и им следуют упуская важное. Так и понятие «full stack framework» в некоторой абстрактной теоретической плоскости. А зачем нам теория? Должны быть практические догмы. На симфони вообще невозможно построить приложение DEV такого же компактного уровня. Как на симфони построить компактное приложение?
На сайте симфони написано — будет PHPBB использовать симфони, но только прошло 3 года а новой версии PHPBB на симфони нет. (я где то читал что собрались форум PHPBB переписать на симфони еще в 2013 году) Команда профессионалов переписывает форум уже 3 года. Браво симфони, работать видимо команде PHPBB легко и приятно, кто только у них придумал переезжать на симфони). Эти ребята всегда писали в глобальную область видимости и сейчас наверно «балдеют» ) Их работа от этого не была менее популярна.
«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.
почему же глупо? Phalcon — php-фреймворк с современным подходом, который вы отрицаете.
Если нужна производительность — то можно взять его.
есть примеры таких приложений?
вот вы пишите про новый подход, что у вас норм код, так что вот это блть значит?
у вас везде подобное, везде магические числа, о подсказках от ide можно забыть, описаний функций/методов нет
и вот такое почти везде. вам то код понятен и кажется простым — вы ж его автор, тупо запомнили. Как мне это дело протестировать? И что сложного в тех ссылках, что я привел ранее?
гибкость, говорите?
как мне сюда отдельное задание добавить? а если заданий будет 100?
прелесть
в общем жду примеров сложных приложений на этом чуде. да даже не сложных, хотя б новостной портал
Если нужна производительность — то можно взять его.
я не то что верю, я знаю, что сайты на 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) инкапсулируют так, что никто нигде не поломает.
Не надо, не надо в JS! Своих хватает
Ну как же, слоган топикастера — будущее за простотой. Запилит модули а-ля is-array из пары строк и всякие left-trim и ими буду пользоваться!
… или стойте, не говорите что....
Ну ладно, раз ниша занята — появится фреймворк isJs из одной строчки: export default const isJs = true;!
Ой, кажется я его уже написал. Прости coresky готов передать его полностью тебе. Только тесты надо дописать.
Заголовок спойлера
Уважаемые JS-ники и coresky, не воспринимайте всё близко к сердцу, это лишь ирония
Я у вас спросил «А зачем ORM вообще?» Первое, что вы мне сказали — короче запись, делаем $user = new User и так мы добавляем нового пользователя. А запись: sql(«insert into users () values ()») намного длинее? Но вы забыли, что вам еще нужно отконфигурировать ORM, так что ничем не короче. Плюс, вы юзаете код ORM который может содержать доп. источник ошибок, изучаете его документацию, понижаете быстродействие.
«right way» и трендовые фреймворк, имхо, это просто игра запутавшихся программистов, которые играют в некотором нереальном поле. На фоне получения удовольствия творчества и довольствования своими способностями, вы не сильно обращаете внимание на реальность. Несмотря на высокий IQ у гуру «right way», вы не можете сбросить шелуху из мыслей и посмотреть на то что происходит чистым взлядом. Имею ввиду то, что я бы назвал «open your mind» (фильм «Вспомнить все»)
Вещи нужно создавать, когда в них есть потребность. По этой причине, я считаю бессмыслено иметь ORM, как дефолтный способ работы с БД, в ваших роутерах просто нет необходимости. Компилируемые шаблонизаторы просто не нужны, потому что шаблоны PHP сами по себе идеально могут справляться с поставленной задачей. Идея twig интересна, но не нужна. И так далее, список могу продолжить.
Из трендовых фреймворк, я отдал бы предпочтение Yii по причине PHP шаблонов и другим вещам. Но критика в его сторону: в примерах которые он приводит, много ненужного кода в файлах представлений. Этого можно и нужно не делать.
MetaDone, я не то что верю, я знаю, что сайты на SKY Framework могут масштабироваться до очень сложных и много функциональных приложений. Результат при этом будет достигаться быстрее и качественнее чем, например, на симфони.
«right way» и трендовые фреймворк, имхо, это просто игра запутавшихся программистов, которые играют в некотором нереальном поле. На фоне получения удовольствия творчества и довольствования своими способностями, вы не сильно обращаете внимание на реальность. Несмотря на высокий IQ у гуру «right way», вы не можете сбросить шелуху из мыслей и посмотреть на то что происходит чистым взлядом. Имею ввиду то, что я бы назвал «open your mind» (фильм «Вспомнить все»)
Вещи нужно создавать, когда в них есть потребность. По этой причине, я считаю бессмыслено иметь ORM, как дефолтный способ работы с БД, в ваших роутерах просто нет необходимости. Компилируемые шаблонизаторы просто не нужны, потому что шаблоны PHP сами по себе идеально могут справляться с поставленной задачей. Идея twig интересна, но не нужна. И так далее, список могу продолжить.
Из трендовых фреймворк, я отдал бы предпочтение Yii по причине PHP шаблонов и другим вещам. Но критика в его сторону: в примерах которые он приводит, много ненужного кода в файлах представлений. Этого можно и нужно не делать.
MetaDone, я не то что верю, я знаю, что сайты на SKY Framework могут масштабироваться до очень сложных и много функциональных приложений. Результат при этом будет достигаться быстрее и качественнее чем, например, на симфони.
Ответ очевиден же, несколько бд не нужно — это все «шелуха из мыслей».
Идеология SKY подразумевает коллективную работу над одними и теми же файлами. Кто угодно, может улучшить в том числе наиболее часто употребимый файл — main/sky.php. У вас же:
такая идеология скоро создаст на пакажист помойку и будет трудно найти хороший пакет так как будет представлено много альтернативных. Имя вендора не имеет ничего общего по отношению к функционалу который он предоставляет, поэтому не должно быть включенно в названии.
Если бы вы «изучили инструмент», то поняли бы, что работа с двумя БД одновременно не является частым случаем (точно менее 30% покрытия) и поэтому в clear-cloud файл не включена. Мое видение, если вам нужно работать с postgresql — просто меняете файл main/sky.php который является портом файла для mysql (clear-cloud). Если работаете с 2 БД одновременно (как раз я работал на Zend так, и считаю их решение уродливым), то вы подгружаете файл третьего крыла (редко употребимый код) и автозагрузчик его использует.
При работе с 2 БД, как правило 1 БД основная и с ней удобнее работать так же как и в приложениях с 1 БД.
структура наименований классов — имя вендора/имя пакета/пространство имен пакета/название класса
такая идеология скоро создаст на пакажист помойку и будет трудно найти хороший пакет так как будет представлено много альтернативных. Имя вендора не имеет ничего общего по отношению к функционалу который он предоставляет, поэтому не должно быть включенно в названии.
Если бы вы «изучили инструмент», то поняли бы, что работа с двумя БД одновременно не является частым случаем (точно менее 30% покрытия) и поэтому в clear-cloud файл не включена. Мое видение, если вам нужно работать с postgresql — просто меняете файл main/sky.php который является портом файла для mysql (clear-cloud). Если работаете с 2 БД одновременно (как раз я работал на Zend так, и считаю их решение уродливым), то вы подгружаете файл третьего крыла (редко употребимый код) и автозагрузчик его использует.
При работе с 2 БД, как правило 1 БД основная и с ней удобнее работать так же как и в приложениях с 1 БД.
Идеология SKY подразумевает в codebase разный код. База кода — это некоторое подобие композер и пакажист. Вы можете туда загрузить этот код.
Я только что установил PHP 7 — все нормально работает. Вроде бы в «right way» у вас short_open_tag должен быть Off — включите его, возможно в этом дело.
Вы просто троллите меня? )
Я только что установил 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 и это хорошо. Это пример как витающие тренды вредят и нужно все воспринимать окружающих холодным рассудком.
Сомнительная необходимость 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, дало прорыв в краткости кода и скорости написания программ в сравнении например с C/C++ при реализации эквивалентного функционала. Привидение типов данных, массивы, хеши, все это супер при применении в веб. У PHP сейчас имеется тенденция к сокращению кода: вместо array() можно писать []. Анонимные функции, Closure. Я это поддерживаю. А у создателей фреймворк тенденция к увеличению кода: мне здесь сказали, что если я пишу function, то правильно писать public function в методе класса и еще много чего… Если отбросить то что вы категорически неприемлете (писание в глоб. область, применение eval, @) — посмотрите код сгенерированного сайта на видео (которое на главной странице проекта SKY) http://ru.coresky.net/download?video1.sky.zip он отличается как небо и земля от NULL сайт на симфони. И при определенных допущениях, по всем показателям лучше эквивалентного на симфони. Он прозрачен как на ладони, он быст и еще много чего. Там много кошерных классных решений.
Я почитаю Брайана Кернигана и Денниса Ритчи больше чем создателей PHP, хотя и их тоже. Надеюсь они не прочтут это и не будут обижены ). Создатели С это первый и самый большой «прорыв». В PHP массивы позволили писать как []. По этой же причине не нужно было вводить ключевое слово function. В языке низкого уровня С его нет, а в PHP (высокого) ввели… напрасно… Откройте любой файл на PHP и удалите слово function везде — он не станет менее читаем, в С же все ок. Вы представляете сколько трудо-часов в мировом масштабе тратятся на абсолютно бесполезные действия и одного из них набирать на клавиатуре слово function? По той же причине я бы еще много чего поменял в PHP, и фреймворках на PHP, но это отдельная тема… Трудно быть именитым…
Я почитаю Брайана Кернигана и Денниса Ритчи больше чем создателей PHP, хотя и их тоже. Надеюсь они не прочтут это и не будут обижены ). Создатели С это первый и самый большой «прорыв». В PHP массивы позволили писать как []. По этой же причине не нужно было вводить ключевое слово function. В языке низкого уровня С его нет, а в PHP (высокого) ввели… напрасно… Откройте любой файл на PHP и удалите слово function везде — он не станет менее читаем, в С же все ок. Вы представляете сколько трудо-часов в мировом масштабе тратятся на абсолютно бесполезные действия и одного из них набирать на клавиатуре слово function? По той же причине я бы еще много чего поменял в PHP, и фреймворках на PHP, но это отдельная тема… Трудно быть именитым…
Когда мне здесь советуют предпочитать строгое сравнение === нестрогому == это значит рубить сук на котором сидишь. Для всех языков программирования разумна может быть только одна тенденция — к сокращению кода. Только так, в частности, область программирования, да и программирование в целом может получить новый значимый прорыв.
И при определенных допущениях, по всем показателям лучше эквивалентного на симфони. Он прозрачен как на ладони, он быст и еще много чего. Там много кошерных классных решений.
а что если я вас скажу, что можно написать без строки стороннего кода и так, что у тех, кто будет читать ваш код, не будут литься кровавые слезы и не появится желания высверлить себе мозг перфоратором? Только для этого нужно немного попрактиковаться и почитать парочку книжек, тыкнуть какие-либо сторонние решения чтоб понять, зачем они так сделали.
Какие у вас там кошерные вещи зарыты в ядре? Пока что все ваши суждения похожи на «всю жизнь ел палочками, даже суп, ложки не нужны, не используйте ложки»
Сомнительная необходимость NAMESPACE
Мое кошерное решение: композер на входе должен иметь PHP парсер кода и БД уникальных имен классов и интерфейсов, дирректорий внутри папки vendor.— зачем?
Сейчас в современном php принята структура наименований классов — имя вендора/имя пакета/пространство имен пакета/название класса
Пример: Aura\SqlQuery\Mysql\Delete
Ваша идея — бессмысленна. Почитайте про psr-4 — что тут непрозрачного? Всегда понятно что и где находится.
Фреймворк должен иметь приложение DEV, как есть в DEV.SKY. Есть зачаток такого приложения в Yii с генерацией файлов CRUD
для симфони вы можете сделать так:
А для 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, его принимают и все пользуются новой фишкой быстро и безболезненно. Если же не принимают — юзаю свой форк с модификациями и радуюсь жизни, так же переподключая в следующие проекты.
Конечно, при условии что я как-то владею инструментом которым пользуюсь и понимаю что делаю. Если же у меня очень ограниченный запас знаний и практики — я запилю свое решение, в котором проигнорирую все лучшие практики и которым смогу пользоваться только я. А все потому, что без базовых знаний не применить все трендовые вещи, которые при понимании оказываются довольно простыми.
Меня поражает, то что вы не можете остудить голову читая что я пишу и одновременно продолжаете следить за топиком. Я бы на вашем месте давно выключил слежение и занялся более полезными делами.
Это элементарно понять что я писал в данном случае не о прозрачности, а о избыточности функционала NAMESPACE.
Все… постараюсь больше не писать сюда ни комментов не статей.
На этом мой бенефис на хабре окончен. Всем спасибо.
— зачем?
Сейчас в современном php принята структура наименований классов — имя вендора/имя пакета/пространство имен пакета/название класса
Пример: Aura\SqlQuery\Mysql\Delete
Ваша идея — бессмысленна. Почитайте про psr-4 — что тут непрозрачного? Всегда понятно что и где находится.
Это элементарно понять что я писал в данном случае не о прозрачности, а о избыточности функционала NAMESPACE.
Все… постараюсь больше не писать сюда ни комментов не статей.
На этом мой бенефис на хабре окончен. Всем спасибо.
В мемориз для книги про пхп. В еверноут залили с комментариями.
С переодичностью раз в несколько месяцев на хабре появляются такие перлы и персонажи, и ты опять не можешь не дочитать всех комментариев автора, ибо это трэш и угар))
Sign up to leave a comment.
Шаблон программирования CSN-Ajax