Из «походного» состояния в рабочее МБС может перейти приблизительно за час: в стороны выдвигаются гидравлические упоры, шасси выравнивается, далее начинается интеграция привезенного оборудования и существующей сети.
На эти манипуляции тратится примерно 10 минут — все происходит в автоматическом режиме штатными средствами КАМАЗа, Ericsson и Alcatel.
А остальное время тратится на выдвижение мачты. Делается это с помощью простого, надежного и элегантного решения инженеров Билайна:
Непонятность у вас возникает из-за того, что вы почему-то разделяете функционал контрола от его дизайна. У «чистых» конролов это разделение на самом деле есть. Если дизайнер меняет контрол исключительно средставими css, то это работает. Но как вы сами выразились, одним css'ом все не решается и в дело вступает программист, реализуя задумки дизайнера (графического или интерфейсного) уже методами яваскрипата.
Возьмем самый простой пример. Вместо кнопки отправки формы дизайнер хочет сделать картинку. В этом случае, возможно, программист и не понадобится — все решается прописыванием элементарных обработчиков событий для картинки.
Другой пример: дизайнер хочет сделать поле ввода с заранее предустановленным значением (например, «введиде e-mail»), которые бы исчезало при получении полем фокуса и снова появлялось, если фокус ушел, но ничего введено не было. При чем эта «подсказка» должна отображаться серым цветом, а введенное пользователем значение — черным. Тут уже программное вмешательство более сильное.
В итоге получается, что над контролом работает и дизайнер, и программист (ну или человек, совмещающий эти две функции). В итоге мы имеем на выходе свой контрол, сильно отличающийся от оригинального. И это всего лишь простое поле ввода. Для более сложных элементов примочек и заморочек будет еще больше. И я еще даже не затронул темы клиент-сайд валидации.
Так вот своим постом я хотел сказать, что чтобы ни придумывали стандартизаторы, все равно будут дизайнеры, которые все также будут использовать старые контролы с примочками и даже на новые контролы прилепят кучу всяких примочек. И таких будет много.
Возможно, непонятность возникла из-за того, что вы под дизайнером подразумеваете чисто визуальщика, а я под понятием «дизайнер» еще подразумеваю человека, занимающегося интерфейсом =)
Граббер (по-вашему лоадер) — это лишь извлечение информации с сайта. И на сколько я понял, с этим у вас ни каких проблем нет. Вопросы у вас возникают с классификацией, упорядочиванием и хранением отпарсенной информации и тут единой методики не существует — все зависит от конкретной задачи.
Ваш алгоритм, на мой взгяд, не плох, за исключением того, что у него иерархаичная классификация. То есть, если марка «ФОРТ», а не «Ford», то система сразу отбросит эту запись для обработки модератором. А могла бы искать дальше, найти «Focus» и поскольку у других марок такой модели нет, сделать вывод, что это все-таки «Ford». Тоже самое касается и модификаци. Я думаю, что найдя классификацию «1.6 Ti-VCT» тоже вполне можно сделать вывод и том что имеется в виду. Но для этого в классификационной базе должно быть двустороннее сопоставление. Если эту систему грамотно выстроить, то модератор будет круглосуточно пить чай, обрабатывая только совершенные ляпы типа «ВАЗ Focus 600» =)
Ну я про внешний вид даже словом не обмолвился — все сказанное про функционал.
А по поводу внешнего вида — тут как раз ни каких проблем нет, поскольку контролы не обязаны выглядеть во всех браузерах одинаково и по умолчанию даже банальные кнопки и чекбоксы в каждом выглядят по-своему.
Визуализация — это уже вопрос не html'а, а css. И я подозреваю, что после устаканивания и принятия стандарта html 5 пойдет вторая волна споров и прений по поводу css, ведь каждый вендор будет пропихивать свою интерпритацию css-свойств для новых тэгов.
Учитывая, что каждый третий дизайнер мнит себя выдаюшимся создателем контролов и непризнанным гением гуи-инженеринга, можно смело заявить: пусть хоть завтра все браузеры будут поддерживать новые спецификации, грамандная масса контролов все также будет представлять из себя html 3.2 с ява-скрипт обвесом.
На эти манипуляции тратится примерно 10 минут — все происходит в автоматическом режиме штатными средствами КАМАЗа, Ericsson и Alcatel.
А остальное время тратится на выдвижение мачты. Делается это с помощью простого, надежного и элегантного решения инженеров Билайна:
%)
Возьмем самый простой пример. Вместо кнопки отправки формы дизайнер хочет сделать картинку. В этом случае, возможно, программист и не понадобится — все решается прописыванием элементарных обработчиков событий для картинки.
Другой пример: дизайнер хочет сделать поле ввода с заранее предустановленным значением (например, «введиде e-mail»), которые бы исчезало при получении полем фокуса и снова появлялось, если фокус ушел, но ничего введено не было. При чем эта «подсказка» должна отображаться серым цветом, а введенное пользователем значение — черным. Тут уже программное вмешательство более сильное.
В итоге получается, что над контролом работает и дизайнер, и программист (ну или человек, совмещающий эти две функции). В итоге мы имеем на выходе свой контрол, сильно отличающийся от оригинального. И это всего лишь простое поле ввода. Для более сложных элементов примочек и заморочек будет еще больше. И я еще даже не затронул темы клиент-сайд валидации.
Так вот своим постом я хотел сказать, что чтобы ни придумывали стандартизаторы, все равно будут дизайнеры, которые все также будут использовать старые контролы с примочками и даже на новые контролы прилепят кучу всяких примочек. И таких будет много.
Возможно, непонятность возникла из-за того, что вы под дизайнером подразумеваете чисто визуальщика, а я под понятием «дизайнер» еще подразумеваю человека, занимающегося интерфейсом =)
Ваш алгоритм, на мой взгяд, не плох, за исключением того, что у него иерархаичная классификация. То есть, если марка «ФОРТ», а не «Ford», то система сразу отбросит эту запись для обработки модератором. А могла бы искать дальше, найти «Focus» и поскольку у других марок такой модели нет, сделать вывод, что это все-таки «Ford». Тоже самое касается и модификаци. Я думаю, что найдя классификацию «1.6 Ti-VCT» тоже вполне можно сделать вывод и том что имеется в виду. Но для этого в классификационной базе должно быть двустороннее сопоставление. Если эту систему грамотно выстроить, то модератор будет круглосуточно пить чай, обрабатывая только совершенные ляпы типа «ВАЗ Focus 600» =)
А по поводу внешнего вида — тут как раз ни каких проблем нет, поскольку контролы не обязаны выглядеть во всех браузерах одинаково и по умолчанию даже банальные кнопки и чекбоксы в каждом выглядят по-своему.
Визуализация — это уже вопрос не html'а, а css. И я подозреваю, что после устаканивания и принятия стандарта html 5 пойдет вторая волна споров и прений по поводу css, ведь каждый вендор будет пропихивать свою интерпритацию css-свойств для новых тэгов.
Короче, браузерная война не закончится никогда =)