если есть значение в работе более мение старых браузеров, следует отказаться от использования текущей версии аякс обвертки, она плохая и необходимо переписать.... в более старых версиях браузера опен должен содержать 3 параметра (третий идет тип запроса, а/синк ), без чего в части случаев плюется ошибка с последующим прекращением сценария. В то же время, современные ее выпиливают но пока принимают но с выбрасыванием уведомления в консоль, что данный подход устарел. Потому однозначное удаление или присутствие третьего значения приводит к ошибке (сейчас для старых из-за отстутсвия или потом при удалении поддержки в современных. Помню, несколько лет назад попал с тем, что удалили поддержку с браузеров чего то с Х, а оно использовалось в каком то сценарии, пришлось срочно выпиливать, хром тогда отличился первым.).
tihov: так, уважаемый... у нас выходит недопонимание....
скрипт о котором изначально была речь, просто для красивого рендеринга жсон респонса по тыцу... он делается за 10 минут (образно говоря о 10 минутах ибо оно оч простое, вопрос только в том, как быстро набрать и подправить для более красивого вида при условии, что есть уже аякс оболочка для отправки и обработки респонсов). А вот момент
прописал подключение к бд, название колонок и все завелось
, как бы выглядит серверным вариантом в виде генерации страницы для выдачи таковой... и это как то не сходится.
Может все же следует определиться, что и какаой кусок должен делать...? Разговора про метеор и тп вообще не идет, на сколько понимаю с присутствия тега php и "подключение к бд"
Данила: эта ситуация, называется ИЕ + мобильные браузеры + тв.
Проблема в ИЕ, не помню до или в какой версии, если задать через баграунд, оно прокликивается, в зис таргета возвращается более нижний слой. Такая же проблема была на андроидах и некоторых "вумных" теликах ранних версий. Пока Вам, уважаемый, приходится представлять эти проблемы, с чем затруднения, мне приходилось на них наступать и вступать... Немного другие траблы были с опасити для слоя или использования rgba.
ну вообщем, если кто подскажет хороший способ, заранее благодарен.
Пока написал пару десятков строк стилей, что бы достичь эффектов, которых мне не хватало с учетом особенностей 2го бс.
ThunderCat: ну если проблема в понимании описанного, значит пока подобное в трудовой деятельности не актуально ибо кто то с более продвинутых среди рабочего коллектива в этой теме и занимается...
Emptyform: нет, предлагается защита данных пользователя при взломах прокладок, допустим между пользователем и конечным ресурсом стоит 100500 промежуточных звеньев.
ssl шифрует общение только между пользователем и хостом, а вот дальше если какую то с прокладок ломанут, результатом будет слитый дамп нешифрованого трафа. При правильной архитектуре, будет стоять задача, как недопустить повтора, а не что делать с пользователями... ибо расшифровка контента будет проходить на каком то с последних этапов, куда редиска не должен добраться. Как то так.
ThunderCat: почитать мануалы по проектированию, что бы понимать, как это работает и подобрать более менее оптимальные условия под текущую архитектуру, возможно с апдейтом таковой.... А как использовать, не понял, в чем прикол вопроса...? Заслал ключи клиенту, публичным получил личный, зашифровал, отдал обратно... Результат с правильной архитектурой, при взломах прокладок, пользовательская инфа при утечке будет неюзабельна.
ThunderCat: советую все же перечитать про открытые и закрытые ключи в криптовании.... бегать к пользователю с флешкой не нужно, если правильно реализовать и этим в вебе пользуются последние лет 7 минимум, даже есть немного самописных либ для реализации разными вариантами. Но массовой популярности не суждено случиться ибо не все девайсы могут корректно работать в столь жестких рамках да и как ранее писал, все, что запускается на клиенте, уязвимо, как ни пляши с бубном...
что то мне кажется, что подключение google e-commerce везде будет одинаково, только нужно понять, что да где вкинуть для корректной работы такового.... было бы странно, что бы гугл делал отдельную версию под какой то непонятный движок...
Immortal_pony: ну при таком подходе, да и вопросе о масках..., смысла дальше писать не вижу и пытаться рассказывать о возможных проблемах. Это только говорит о том, что не приходилось делать что то серьезнее сайта визитки или натяжки магазинчика на какой то движок....
Immortal_pony: Если коротко, с перезагрузка страницы == потеря состояния, танцы с бубном для сохранения и последующего считывания, возможности проблем с созданием маски и прочие бока... вообщем эффективность подобного значительно ниже, а проблем больше...
пысы: приходилось поддерживать в шаблонах до 26 локализаций и долгое время работали как раз по перезагрузке, потому знаю, что пишу...
Immortal_pony: на вопрос "Почему?" -- часть ответа находится ниже вопроса, в том, что отмечено вопросом "Это что вообще за поток созанания?", так же еще частью может быть в особенности работоспособности стореджа и БД
WildKayote: вопрос был не в том, как оформить, а в самой валидации, как сделать... вот и написал более правильный вариант, что введенный контент засылается на сервер для всех нужных манипуляций и анализа вообще того, что вводят пользователи.....