Здравствуйте, Alekzander, Вы писали:
A>Ещё раз извиняюсь за то, что я не смогу эту тему поддерживать в будущем, писать долго приходится, у меня времени столько нет.
Впрочем, ладно. Есть время, нет время — как же не оседлать любимого конька. Готов, в общем, со своей стороны поддерживать эту тему сколько потребуется.
А пока добавлю ещё кое-что про контролы. С моей точки зрения, контролы всегда были очень плохим решением для UI. Легче всего показать это на следующем примере. Была такая библиотека — MFC. На ней писали приложения типа Блокнота или Ворда — создал документ, отредактировал документ, сохранил документ, открыл документ, снова отредактировал. (И ещё распечатал документ — тогда это было актуально). MFC предлагала удобную абстракцию — представление документа. Как в таких случаях поступал нуб, соблазнившись визивигом? Он выбирал представление на основе диалогового окна (дай бог памяти, CFormView это называлось). Это представление умело грузить форму из ресурсов, а в ресурсах её можно было редактировать визуально, набрасывая на неё контролы. Особенно часто этим грешили дельфишники, у которых идеология контролов была возведена в абсолют (вплоть до невизуальных контролов).
Я помню гениев, которые писали приложение для (условно) картографии с задачей коммивояжёра, и для того, чтобы сделать многоточечный маршрут, натурально создавали во всех возможных точках маршрута радиобаттоны. Кликая по которым, юзер описывал граф. И дополнительную информацию (поверх карты) они тоже выводили, сделав отдельный контрол. Кстати, ActiveX-контрол. Кто работал с ActiveX, тому, наверно, уже смешно, как всё это работало. Градиенты в альфа-канале особенно. Если кому-то не смешно, предлагаю подумать, какой комбинацией контролов можно реализовать представление вордовского документа. (Если самому писать, а не брать готовый у Майкрософта, как сделал я, приспособив для этого браузер).
В общем, контролы у представлений-монолитов просасывали со страшной силой. Если создать требовалось высококачественное приложение без компромиссов между "хочу" и "могу", требовалось взять базовый класс CView и пилить всё самому, от A до Я, утрясая порядок отрисовки разных данных в разных режимах. Но, к сожалению, монолит имеет и свои недостатки. Монолитное представление быстро превращалось в неконтролируемо разраставшийся файл от десятков тысяч строк, в котором трудно разобраться.
HTML же (как яркий представитель маркапной парадигмы) позволяет взять лучшее от обоих подходов. Можно обходиться без контролов, соответственно, не имея проблем с тем, как одни данные отображаются поверх других, или произвольно вкладывая разные части интерфейса друг в друга. И при этом — никакого многотонного файла-всемогутора. Это происходит в том числе за счёт стилей, например, определяющих порядок отрисовки. Разные режимы отображения могут просто опираться на разные наборы стилей. И так далее.
Не знаю, понятно ли получилось написать. Для понимания крайне желателен бэкграунд в виде работы над интерфейсами, когда ты не можешь отмахнуться от требований "сделать как у Майкрософт", просто налепив говноконтролов на форму.
