Ну конкретно я столкнулся с проблемой одновременного выбора нескольких размеров одежды, когда начал делать остров для своего сайта… делать 20 чекбоксов — слишком громоздко, а селект позволяет выбрать только один элемент…
Предвижу, что ещё столкнусь с этой проблемой при выборе страны производителя…
Да и в том самом примере поиска авто, который приведен в документации… если я ищу седан или хетчбэк… мне придётся 2 раза искать…
А вообще множественный выбор — это стандартная логическая конструкция: "… AND x in (a,b,c,d )… "
ещё не хватает такого элемента, как выпадающий список с одновременным выбором нескольких вариантов…
по крайней мере в документации я не нашёл такого :(
Можно ли будет привязывать к сайту несколько островов?
Например у нас в магазине несколько типов товаров и для каждого типа есть уникальные характеристики… Если перечислить их все — остров будет очень большой и сложный для пользователя… а так при поиске покажется наиболее релевантный остров, где будут характеристики уже конкретной группы товаров.
На Philips W732 сильные тормоза (при полном отсутствии оных на старой версии). Заметное долгое время отклика на нажатие (полсекунды точно). Размытие при масштабировании и отрисовка «секторами», т.е. получается что при увеличении я сначала вижу размытое изображение во весь экран, потом он делится на квадраты 6-8 квадратов и с видимой задержкой каждый квадрат становится четким — очень необычно это выглядит. Так работать не комфортно.
+ что ещё разочаровало — это то, что опера теперь масштрабирует основной текст страницы, делает его крупнее задуманного и тем самым сайты смотрятся нелепо и местами едет вёрстка. Старая опера отрисовывала точ-в-точ как на десктопе.
Может быть вы оставите старую версию, как отдельное направление? Мне она больше нравилась.
Всё это напоминает историю с qip в своё время. Вроде хотели как лучше, а до сих пор все многие пользуются старым квипом и не спешат обновляться.
Эм… вы поставили меня в тупик :) Задача была несколько другая… видимо я что-то неправильно понял. Задача заключалась в выкладывании dev базы на продакшен… для этого нужны было найти отличия dev версии и сгенерировать файл, приводящий продакшн к состоянию dev версии.
В данном случае скрипт бы дропнул b и c и создал бы новые поля d и е.
Полноценный анализ, конечно, на коленке не напишешь… да и без истории изменений или человеческого вмешательства не обойтись…
Что касается конкретно того скрипта, который я писал — он создавал массивы со структурами обеих баз, сравнивал — записывал результаты сравнения в другой массив (какие таблицы и поля добавились, какие изменили свой тип или другие атрибуты, какие удалились) и на его основе генерировал sql запросы. Аналогично потом пробегал по самим данным.
Было не сложно, ибо всегда одна база была ведущая, а другая отстающая — надо было отстающую обновить до состояния ведущей, а не делать общую базу на основе обоих.
Я когда на работу устраивался — это было моим тестовым заданием — написать скрипт, который сравнит 2 mysql базы и выдаст sql файл, которые приведёт одну базу к состоянию другой. (структура + опционально данные)
В общем примерно за час я накидал более-менее работоспособный прототип, дальше делать не стал — так взяли :)) при желании за вечер можно написать полностью :)
а мне кажется, что наоборот… общество не должно проводить грань между инвалидами и не инвалидами… но некоторые виды работы инвалиды в виду своих особенностей сделать не могут… если это помечать сразу, чтобы такие люди не тратили своё время на эту вакансию… а по умолчанию все вакансии были бы доступны длля всех… но тогда нужно разделить их по характеру инвалидности и ставить более расширенные галочки…
мне кажется, что именно так должно быть в цивилизованном обществе…
Предвижу, что ещё столкнусь с этой проблемой при выборе страны производителя…
Да и в том самом примере поиска авто, который приведен в документации… если я ищу седан или хетчбэк… мне придётся 2 раза искать…
А вообще множественный выбор — это стандартная логическая конструкция: "… AND x in (a,b,c,d )… "
по крайней мере в документации я не нашёл такого :(
Например у нас в магазине несколько типов товаров и для каждого типа есть уникальные характеристики… Если перечислить их все — остров будет очень большой и сложный для пользователя… а так при поиске покажется наиболее релевантный остров, где будут характеристики уже конкретной группы товаров.
+ что ещё разочаровало — это то, что опера теперь масштрабирует основной текст страницы, делает его крупнее задуманного и тем самым сайты смотрятся нелепо и местами едет вёрстка. Старая опера отрисовывала точ-в-точ как на десктопе.
Может быть вы оставите старую версию, как отдельное направление? Мне она больше нравилась.
Всё это напоминает историю с qip в своё время. Вроде хотели как лучше, а до сих пор
всемногие пользуются старым квипом и не спешат обновляться.В данном случае скрипт бы дропнул b и c и создал бы новые поля d и е.
Полноценный анализ, конечно, на коленке не напишешь… да и без истории изменений или человеческого вмешательства не обойтись…
Что касается конкретно того скрипта, который я писал — он создавал массивы со структурами обеих баз, сравнивал — записывал результаты сравнения в другой массив (какие таблицы и поля добавились, какие изменили свой тип или другие атрибуты, какие удалились) и на его основе генерировал sql запросы. Аналогично потом пробегал по самим данным.
Было не сложно, ибо всегда одна база была ведущая, а другая отстающая — надо было отстающую обновить до состояния ведущей, а не делать общую базу на основе обоих.
В общем примерно за час я накидал более-менее работоспособный прототип, дальше делать не стал — так взяли :)) при желании за вечер можно написать полностью :)
Могу поменять на инвайт на турбофильм :)
Расскажите это фрезировщикам :)
мне кажется, что именно так должно быть в цивилизованном обществе…