Так что совет — используйте подготовленные выражения. А еще лучше популярные абстракции над уровнем даннных — это позволит избежать возможных проблем при миграции, а также снимет часть типовых задач.
filter_var
О встроенный валидатор email в php я уже однажды обжегся. После этого везде использую валидатор yii(выдранный или вместе с фреймворком — в завсимости от ситуации).
Автору поста.
В файле index.php (или в любом другом главном файле) напишите такую строчку перед подключением других php файлов
Это действительно совет? Если да, то поясните при каком подходе к разработке приложения проблемы с инклудами нужно решать именно таким образом, пожалуйста.
В этом случае администратору править проще в административной панели свойства страницы настроек.
Показал этот текст заказчикам, которым я решал задачи по автоматизации — дружно посмеялись. Дико. Дикая у вас работа. Хотя, возможно, только при использовании таких подходов этот 'администратор' и будет нужен.
Уж лучше вынести правила округления в настройки и ничего что левая и правая границы не будут фактически существовать(12000 вместо 12133 и 22200 вместо 22293) — все равно у нас операция 'МЕЖДУ'. Только шаг продумать, чтобы клиент не смог сам себя в угол загнать( диапазон от 12000 до 12132 например).
Ваши слова не лишены смысла. Но владельцы мобильных устройств без поддержки flash совсем не поймут о чем вы.
В современных реалиях подобная мелочь как jQuery/jQuery UI если и будет вас беспокоить, то только как статика, которую нужно отдать.
Так вроде браузеры такой бедой уже не страдают. Я во всяком случае в этом уверен.
Можно пример страницы с бесконечными алертами, от которых не поможет отбиться последний FF/Chrome/Opera?
Она есть. Создаете пустой проект, настраиваете remote host, cкачиваете себе ваш settings.php(сохраняя структуру папок), правите на своем компьютере и загружаете на удаленный хост. Оч просто, кстати :D
У JetBrains по моему опыту просто волшебная служба поддержки клиентов. Посему, если бы вы им написали, что у вас есть трудности с установкой JDK, думаю они бы с удовольствием помогли.
PS: Насколько я понимаю их политику — если пользователи голосуют за определенный запрос, JetBrains его реализуют. Видимо за OpenJDK не так много народу голосовало.
Тут было чуть попроще — я наладил обмен между ERP и e-commerce системой и с новыми данными половина системы не завелась. Из-за хардкода id, названий, неявных параметров.
Так что тут либо отказываться от обмена, либо переписывать компоненты. Заказчик в тему вьехал и дал добро.
У меня недавно был проект без архитектуры на инклудах, где магическая переменная магической погоняет. Это настолько классический случай лапши и плохого дизайна, что все сурсы можно запросто выкинуть на govnocode и получить +300 их рейтига.
Тогда я честно сказал заказчику, что если он хочет от меня что-то новое или правки старого функционала, это значит что мы будем удалять(выжигать железом) старый код и внедрять новый.
Понимаю, что не всегда дают деньги и время на это, но если нет времени на рефакторинг, значит с менеджментом что-то не так.
ИМХО если мы тыкаемся в legacy код и видим в нем грязные mysql_ с невнятным поведением при некорректных аргументах — мы просто берем и заменяем эти вызовы на *ABSTR_DB_LAYER* (мы же новый код не по тем же принципам пишем, верно? у нас абстракции, модульность, программирование на уровне интерфейсов и вообще лучшие практики курят в сторонке).
Первое правило: Никому не говорить о php клубе.
Второе правило: Вообще не говорить о phpклубе.
Третье правило: Крикнул «СТОП», выдохся, отключился — php окончен.
Четвертое правило: Программируют только двое.
Пятое правило: Не допускаются написание двух вещей одновременно.
Шестое правило: Без обуви, без рубашек.
Седьмое правило: Программирование длится столько, сколько нужно.
И восьмое, последнее правило: Если это ваша первая ночь в php клубе, вы должны программировать.
PDO никак не человека, писавшего
Так что совет — используйте подготовленные выражения. А еще лучше популярные абстракции над уровнем даннных — это позволит избежать возможных проблем при миграции, а также снимет часть типовых задач.
О встроенный валидатор email в php я уже однажды обжегся. После этого везде использую валидатор yii(выдранный или вместе с фреймворком — в завсимости от ситуации).
Автору поста.
Это действительно совет? Если да, то поясните при каком подходе к разработке приложения проблемы с инклудами нужно решать именно таким образом, пожалуйста.
Показал этот текст заказчикам, которым я решал задачи по автоматизации — дружно посмеялись. Дико. Дикая у вас работа. Хотя, возможно, только при использовании таких подходов этот 'администратор' и будет нужен.
Уж лучше вынести правила округления в настройки и ничего что левая и правая границы не будут фактически существовать(12000 вместо 12133 и 22200 вместо 22293) — все равно у нас операция 'МЕЖДУ'. Только шаг продумать, чтобы клиент не смог сам себя в угол загнать( диапазон от 12000 до 12132 например).
В современных реалиях подобная мелочь как jQuery/jQuery UI если и будет вас беспокоить, то только как статика, которую нужно отдать.
Так вроде браузеры такой бедой уже не страдают. Я во всяком случае в этом уверен.
Можно пример страницы с бесконечными алертами, от которых не поможет отбиться последний FF/Chrome/Opera?
PS: Насколько я понимаю их политику — если пользователи голосуют за определенный запрос, JetBrains его реализуют. Видимо за OpenJDK не так много народу голосовало.
PS: О, времена, о непрекращающиеся подстрекатели к святым войнам. Меча на вас нет :)
Так что тут либо отказываться от обмена, либо переписывать компоненты. Заказчик в тему вьехал и дал добро.
У меня недавно был проект без архитектуры на инклудах, где магическая переменная магической погоняет. Это настолько классический случай лапши и плохого дизайна, что все сурсы можно запросто выкинуть на govnocode и получить +300 их рейтига.
Тогда я честно сказал заказчику, что если он хочет от меня что-то новое или правки старого функционала, это значит что мы будем удалять(выжигать железом) старый код и внедрять новый.
Понимаю, что не всегда дают деньги и время на это, но если нет времени на рефакторинг, значит с менеджментом что-то не так.
Первое правило: Никому не говорить о php клубе.
Второе правило: Вообще не говорить о phpклубе.
Третье правило: Крикнул «СТОП», выдохся, отключился — php окончен.
Четвертое правило: Программируют только двое.
Пятое правило: Не допускаются написание двух вещей одновременно.
Шестое правило: Без обуви, без рубашек.
Седьмое правило: Программирование длится столько, сколько нужно.
И восьмое, последнее правило: Если это ваша первая ночь в php клубе, вы должны программировать.
Споры о языках разных.
Секса нехватка…