@Petroveg Ну у человека же тоже могут быть требования, ни кто ему не мешает задать свои условия для email, по этому я не рассказывал, про его странность проверки, и мой самый первый результат был согласно его запроса. Это уже дальше человек вспомнил, про "букв, цифр , символов и дефиса", поправили задачу под второй набор требований.
И вообще email правильно регуляркой не проверить, очень уж он разнообразный бывает.
@Petroveg ну вы уже тут придирайтесь.
Я человеку выше написал, что мое решение не окончательное и будет пропускать специфические email, если на то пошло, то дефолтная регуляка в input[type=email], самая правильная, т.к в теории test@test являться валидным email, так что тут точка совсем не обязательна, кто мне мешает купить домен первого уровня))) Так, что я не понимаю, почему топик стартера она не устроила...
Если на то пошло, то есть гугл, там можно найти финальную регуляку со всеми возможными вариантами, но она тоже не идеальна, т.к email это очень специфичная штука и ее очень сложно правильно проверить, т.к теперь есть национальные домены, на китайском, на русском и т.д, или с умляутами, грубо говоря во всем спектре юникода.
@Petroveg Что Вы этим хотите сказать?, конечно кусочек этот будет true, так вы полностью регулярку проверьте, а я выше написал, что мое решение не идеальное, но большую часть email проверит, как надо. если уж проверять надо, то нужно весь спектр email рассмотреть, а там регулярка выйдет ой, какая большая...
@grigor007 В REQUEST_URI попадает вся часть после домена, к примеру host.com/form/%22%3E%3Cscript%3Ealert('xss')%3C/script%3E%3Cbr%20class=%22demo, вот окажется REQUEST_URI все, что после .com
@Taraflex перед @ точка есть, смотрите начало в [], а после @ она не нужна, т.к dasdsad@.test.ru это не валидный email. Или я не прав? если да, то почему?
@realt
^([-\w.]+@[-A-Za-zА-Яа-яёЁ0-9]+\.+[A-Za-zА-Яа-яёЁ0-9.]+)$
Проверяет еще кириллические домены. И да, формат email очень длинный, какие-то специфические адреса может не пропустить, т.к полная регулярка на проверку очень-очень длинная.
эта пропустит все основные email. тестить можно тут - regex101.com/#javascript
@Haddly mysql_* Вообще deprecated...
Да, согласен можно пользоваться нативными возможности, без всяких там ORM, шаблонизаторов и т.д. Пока Ваш проект простой, бложек какой-нить, или Home Page или подобное не превышающие 5к строк кода.
А теперь представьте ситуацию, если у Вас сложная CRM система, высоконагруженная, более 80к+ строк кода, множество абстракций, взаимодействие с разными базами, множество различных форм и т.д
И тут вдруг выяснится, что MySQL больше не справляется с нагрузкой вашего проекта, и в срочном порядке нужно организовать переезд на PostgreSQL\Oracle иль NoSQL БД, а у вас весь проект не дай бог на mysql_*, ой тогда я Вам не завидую...
Или пример из ORM, с объектом то куда проще работать, с чем native что возвращает ваш любимый mysql_*. Представьте себе, что потребуется результаты выдачи базы обрабатывать разными фильтрами, с ORM куда проще будет это сделать. ORM вообще решает многие проблемы, т.к вы работаете с объектами, а не native результатом, а тут можно и наследование и инкапсуляцию, и полиморфизм, да как надо, так и будете свой объект использовать... И это только верхушка того, что может ORM.
Пример с формами, конечно на HTML очень просто, а если у Вас в проекте около 1000 различных форм, и вам потребовалось добавить во все формы crfs token, представьте только, сколько вы потратите времени на рефакторинг каждой формы, а используя бы Form Model, вы просто бы отредактировали базовый класс и было бы счастье.
Так же формы удобно использовать для их валидации, ведь прежде чем использовать данные из нее где-угодно, они же должны быть правильные, ну там обязательные поля и т.д. А о этих правилах, кто-то же должен знать, так что объект формы опять спасает вас.
Пример с шаблонизаторами, тут мнения расходятся, даже у меня :)
С одной стороны шаблонизатор это хорошо, а чем же PHP и short tags не шаблонизатор?, явно быстрее все решений будет.
PHP и short tags точно плюс скорость, простота и т.д
Шаблонизаторы, уступают в скорости, хотя не всегда, так что это уже можно и не учитывать.
Что касается Smarty, так он ничего нового не дает по сравнению с PHP, что насчет Twig, тоже ничего особенного, ну только если наследование шаблонов, реально крутая штука, ну может еще в плюс к шаблонизаторам, что они инкапсулируют данные.
Вообщем по шаблонизатором аргумента нет :)
Насчет ZF2 и 12 проектов, ну не все же проекты туда попадают, их гораздо больше, сайт триколор ТВ например :), Вообщем кол-во проектов на офф. сайте это не показатель :)
@nepster09 Сходу так прям не ответить, всего скорей это не удачное решение, т.к получаем связь блога и сообщений, с другой стороны если система не сложна, то вполне себе решение.
Если делать через трейты, я бы наверное сделал следующем образом, трейт отвечал бы за получение экземпляра конкретного модуля, ну через какой-нить контейнер зависимостей, подключал в него все зависимости т.д.
trait UserModuleTrait
{
protected function getUserModule() { // логика создания }
}
В модели блога подключал бы этот трейт, и через него получал связь с модулем пользователей, а через модуль пользователей на модуль сообщений и отправлял сообщение бы.
Но тут получается такая страшная штука, если условия отправления сообщений сменить с 10, на к примеру каждого 3 отправленное в субботу утром, то получается постоянно лезть в модель блога для исправления.
Всего скорей тут лучше сделать через эйвент по факту создания новой записи, это эйвент отлавливать и уже в обработчики реализовать всю логику по отправки сообщений. А сами связи на модуле получать через контейнер сервисов, ну так будет правильнее...
Хотя еще раз повторюсь, если проект не сложный, то первый вариант вполне себе рабочее решение :)
@nepster09 Но только если вы трейты будете использовать, как обертку над локатором, di, или чем-то подомным. Иначе я не совсем понимаю, как вы хотите наладить этот мост...
@Fesor Не соглашусь насчет макроса и того, что код вставляется в место use TraitName, в PHP это реализовано, почти так же, как extend, за исключением приоритетов, кто кого перекрывает. ну и да одноименные функции из трейтов друг друга перекрыть не могут, будет ошибка, но есть механизм выбора.
Насчет множественного наследования, это было в качестве примера, множественное наследование вообще штука не очень хорошая, но при грамотном и острожном использование пойдет :)
@invaest Так это очевидно ругается когда еще файл не загружали? т.к вы обращаетесь к этому индексу вне условия проверки. Дайте уже полный код файла upload, на почту можно korsar.zn@gmail.com
SELECT * FROM category
LEFT JOIN (SELECT tt.category_id, COUNT(p.*) AS cnt FROM product AS p WHERE p.color = "red") AS tt ON tt.category_id = category.id
WHERE category.id IN (1,2,3...)
ORDER BY tt.cnt DESC
@invaest сделайте echo 1, перед запросов в БД если выведет, значит в условие заходит, если нет, значит условие не срабатывает, тогда будем думать дальше.
@invaest
Так у Вас условие не выполняется, всего скорей вы не правильно делаете загрузку файла из формы, она обязательная должна иметь атрибут enctype="multipart/form-data"
И вообще email правильно регуляркой не проверить, очень уж он разнообразный бывает.