Наткнулся на такую багу в браузере Chrome Beta под андроидом.
Вот ссылочка на сайт, где вылезла эта проблема http://m[dot]aerolofts[dot]ru/loft-rezid[dot][dot][dot]irovki-i-tseni/1
Видите белый прямоугольник с надписью "Выберите"? Так вот, если тапнуть по нему (по стрелочке), то список не выпадает, хоть и должен.
Но если тапнуть чуть выше этой белой облости то событие срабатывает и список выпадает.
Будто браузер проецирует элемент над его отрисовкой на странице, что очень странно.
Почему я виню хром? Потому что, эмпирическим путём было доказано, что эта "штука" работает во всех браузерах, кроме Chrome Beta (и может быть Chrome, не ставил, не пробовал).
GoDr, не люблю оффтопить, это будет последний в этой теме. Если хочешь критики - создавай отдельную тему.
Namespace появились в 5.3 и не просто так. Это действительно удобно.
Например, класс mod_boss_content_Helper можно поместить в namespace mod\boss_content а сам класс назвать Helper, без лишних префиксов.
Ещё для автозагрузки пространства имён используются, например, в PSR-0, PSR-4. Для классов пространства имён полезны и уместны всегда.
Абстракции хороши там, где нужны. Без абстракций не будет полиморфизма. И что бы код был более гибким, приходится постоянное рефакторить, выделять абстракции, интерфейсы итд.
Злоупотреблять этим, конечно, плохо а исключать это из своего рациона глупо. Лучший путь - срединный путь.
Лучше почитай код какого-нибудь фреймворка, например, yii2 (да, да, опять я с этим yii2), он простой и понятный и по стандартам.
Я и сам миддл, так, что прислушиваться к моим советам или нет - решать тебе.
Времени у меня практически нет свободного, но на обсуждения найдётся.
GoDr, да-да, DeepVarvar прав.
Что сходу не понравилось:
1. Фронт контроллер какой то жирный.
2. Написано, что минимум PHP 5.4. А где пространства имён?
3. Этот пункт, наверное, имхо, но где coding standart, например, PSR-2? Или тут используется какой-то другой стандарт? Или всё-таки собственно-придуманный?
Так, пробежался по паре файлов. Холивар разводить не буду, нет желания.
в таком случаэ нету проверки на подлиность логина пароля, их существования
так добавь.
Я показал стиль написания, исправил банальные ошибки, в том числе sql инъекцию, а дальше сам думай, что делаешь не так. Мне даже тыкать пальцем не хочется, настолько это банально.
Документацию в руки и пошёл учить, в документации всё есть. http://php.net/manual/ru/mysqli.query.php (Добавление)
Ну молодец. Сессии? Запускай в начале скрипта (session_start()) и используй.
Разница в только в том что я предлагал ответ слать не на заранее известный адрес а сообщать его в запросе
ну, тут нужно, что бы данные не пришли на левый домен, иначе всё было бы проще.
Переданные Адрес + Ключ служат для аутентификации.
LIME пишет:
И статус завершения я предлагал получать не от сервера а опрашивая локальное состояние
но зачем? Сервер по завершению сам скажет, что данные отправлены. Раньше ответа сервера делать локальный опрос не рационально, имхо.
В п1.1.1 можно даже вернуть ответ серверу после получения данных.
Вариантов много, и как ты и сказал, всё это детали реализации. (Добавление)
Вот, что интересно, можно ли п1.1.1 отправить по https не имея https на клиенте?
iddqd
1. Зачем его отключать в коде? Вся админка будет одностраничной, построенная на emberjs или подобном фреймворке.
2. Если не пройдёт, то выведется сообщение об ошибке, это же не сложно отследить.
Тут подразумевается, что клиент (который заказчик, тот кто купил лицензию) не будет лезть своими руками в код.
Если и полезет - на его страх и риск.
Всё это, конечно, ценные мысли, но вопрос в том, как максимально безопасно передать данные клиенту.
Вот, набросал ещё 1 схему.
Достоинства:
1. Минимум запросов.
2. При хищении ключа, данные всё равно придут на нужный домен, а там уже будут решать, их это данные или кто-то от их имени делал запрос.
3. Что-то ещё?
Недостатки:
1. Пока не вижу, может завтра увижу косяки.
Схема открыта для обсуждений, пишите свои мысли.
P.S. Не обращайте внимание на нумерацию, программа сама понаставила.
Я понял, почему http мне не подходит. Ключ соединения же должен проверяться на сервере а не на клиенте.
В случае с http, нельзя проверить ключ на сервере, так как второй запрос делается с сервера и в нём должны передаваться запрошенные данные.
В случае с сокетами всё проще, сервер коннектится к клиенту, клиент посылает ключ, сервер проверяет и принимает меры. (Добавление)
Да уж, с сокетами возникает та же проблема, только вид сбоку.