нужен ли отдельный язык для описания gui ? [re: [ньюб QT] queued .. ]
В общем, мне не очень понятно, почему в большинстве современных RAD-системах гуистроения применяется описание интерфейса в виде кодаэто делается для того, чтобы:
1. в идеале - можно было использовать конструкции языка (выражения, переменные, if-ы, циклы, ссылки и т.д.) для описания формы.
2. был минимальный барьер между созданием чего-либо через дизайнер и через код
но в реальности - п.1 не выполняется, т.к. парсер дизайнера эти навороты все равно не осиливает.
а на п.2 забивают или решают через максимальное приближение конструкции из декларации к конструкциям из кода
1. в идеале - можно было использовать конструкции языка (выражения, переменные, if-ы, циклы, ссылки и т.д.) для описания формы.что мешает сделать гетерогенную систему, наподобие DOM, что я уже предлагал
что мешает сделать гетерогенную систему, наподобие DOM, что я уже предлагалкак это помогает использовать те фишки, которые я упомянул?
+ как решать проблему с рефакторингом?
как это помогает использовать те фишки, которые я упомянул?1. В тексте программы мы сами выбираем какой способ использовать: статический (со схемой) или динамический с кодом. При этом имеем возможность их комбинировать, то есть генерировать некоторые части интерфейса различными методами, но при этом они всё равно смогут ссылаться друг на друга. Помимо этого есть возможность накладывать статические схемы на динамическую структуру, создавая при этом нехватающие виджеты и применяя настройки пропертей к существующем динамическим виджетам.1. в идеале - можно было использовать конструкции языка (выражения, переменные, if-ы, циклы, ссылки и т.д.) для описания формы.
2. был минимальный барьер между созданием чего-либо через дизайнер и через код
2. Собственно такую задачу я не ставил, но она решаема.
2.1 Дизайнер -> код. Дизайнер выдаёт строку, содержащую статическую схему распределения виджетов. Программист либо копирует эту строковую константу куда-либо, либо она кладётся в некоторое дефолтное место в гуи классе.
2.2 Код -> Дизайнер. Дизайнер браузит код и находит подходящую функцию, прогоняет её на интерпретаторе, результат отображает в статике. При этом либо программист сам указывает эту функцию в коде и параметры к ней, либо берётся функция с дефолтным именем, и её передают дефолтные параметры, либо объявляется специальная функция-генератор preview, которая передаёт искомую функцию и несколько наборов параметров, для каждого из которых дизайнер рисует формочку.
Понятно, что второй вариант происходит с потерей данных, поскольку из динамики статику получить нельзя. Но дизайнер можно использовать для просмотра некоторых ожидаемых вариантов использования динамического кода. Большего было бы странно требовать.
+ как решать проблему с рефакторингом?что именно ты подразумеваешь под рефакторингом?
это делается для того, чтобы:О пунктах 1 и 2 применительно к Delphi:
1. в идеале - можно было использовать конструкции языка (выражения, переменные, if-ы, циклы, ссылки и т.д.) для описания формы.
2. был минимальный барьер между созданием чего-либо через дизайнер и через код
но в реальности - п.1 не выполняется, т.к. парсер дизайнера эти навороты все равно не осиливает.
а на п.2 забивают или решают через максимальное приближение конструкции из декларации к конструкциям из кода
1. Создание кучи компонент в цикле при создании формы - вполне стандартная задача, имеющая стандартное решение. При этом, компоненты ты можешь создавать не только из кода, но и из компонентного потока. Тоже, кстати, стандартная задача.
2. преобразование дизайнер -> код - однозначно и тривиально (в силу простоты компонентного потока возможности делать это автоматом из среды нет, наверное, потому, что это никому не нужно; обратное преобразование пишется в три строчки и может выполняться через единичный запуск приложения. Пожалуй, нельзя это назвать минимальным барьером, но с другой стороны, в качестве бонуса мы получаем отсутствие длинной, трудно редактируемой вручную (т.к. банально в таком коде слишком много воды) кучи кода внутри одной функции.
Преимущество специального языка для описания интерфейса в том, что он специально для этой цели разработан. А если говорить другими словами, то процесс загрузки формы - это, фактически, исполнение байт-кода, а при таком рассмотрении, единственное отличие двух способов в том, что в случае с Delphi мы используем правильный инструмент, а создатели, например, WindowsForms до правильного инструмента не додумались и у них получился какой-то изврат. Кстати, циклы в Delphi-шном описании форм вполне реализуемы, готов на спор реализовать циклы (естественно, не ниже уровня отдельных компонент, т.е. внутри описания свойств компоненты они бессмысленны) для дизайнера Delphi, ссылки уже реализованы "из коробки" в виде фреймов, с ветвлениями сложнее, т.к. вырезать что-то из компонентного потока при загрузке нереально, однако можно устроить авто-убиение компонента по условию, хотя не вижу причины, по которой это не должно быть в обработчике OnCreate.
2.1 Дизайнер -> код. Дизайнер выдаёт строку, содержащую статическую схему распределения виджетов. Программист либо копирует эту строковую константу куда-либо, либо она кладётся в некоторое дефолтное место в гуи классе.Если синтаксис описания дизайна тривиальный, то и преобразование в код должно быть тривиально, можно даже расширение для IDE реализовать, которое будет заниматься таким преобразованием.
Преимущество специального языка для описания интерфейса в том, что он специально для этой цели разработан.переменную в этот язык вставить можно? а выражение?
если нет - то это плохой язык
+ как решать проблему с рефакторингом?да-да, код, который выплёвывает дизайнер определённо необходимо рефакторить... Одна только проблема: после рефакторинга дизайнер перестанет работать. К слову, об убожестве WindowsForms:
Почему, когда я использую #region в коде у меня такое ощущение, что я вместо того чтобы убрать в комнате бардак, тупо прикрываю его одеялом и делаю вид что так и надо...
переменную в этот язык вставить можно? а выражение?Продолжаю твою мысль. HTML - плохой язык разметки гипертекстовых документов, так как там нет ни переменных, ни выражений. И о чём только создатели WWW думали? Впрочем, есть же JavaScript. Давайте отменим HTML и будем делать все страницы на JavaScript'е, ведь у него есть все средства для построения DOM-дерева. =)
если нет - то это плохой язык
что именно ты подразумеваешь под рефакторингом?как минимум - изменение имен контролов, имен обработчиков и т.д.
Продолжаю твою мысль. HTML - плохой язык разметки гипертекстовых документов, так как там нет ни переменных, ни выражений. И о чём только создатели WWW думали? Впрочем, есть же JavaScript. Давайте отменим HTML и будем делать все страницы на JavaScript'е, ведь у него есть все средства для построения DOM-дерева. =)дихотомическое мышление - это конечно круто, но лучше двигаться дальше...
html - очень примитивный декларативный язык (xaml, язык дельфевых форм и т.д - тоже).
javascript - императивный язык.
но для описания форм нужен мощный декларативный язык.
вот, например, css - уже шаг в этом направлении (в нем уже есть недопеременные, и недо if-ы)
Почему, когда я использую #region в коде у меня такое ощущение, что я вместо того чтобы убрать в комнате бардак, тупо прикрываю его одеялом и делаю вид что так и надо...так можно сказать про любой инструмент.
ссылки уже реализованы "из коробки" в виде фреймовкак сделать чтобы кнопки внутри панели mypanel были одного цвета, и этот цвет брался из одного места?
как сделать чтобы кнопки внутри панели mypanel были одного цвета, и этот цвет брался из одного места?Пример неудачный: цвет кнопки под виндой изменить не совсем тривиально.
А вообще, делается это тривиально, т.к., шрифты, цвета, объёмность отображения, направление текста и отображение (или неотображение) подсказок могут наследоваться от родительских (не в смысле наследования классов, а в смысле расположения одних контролов внутри других) элементов управления. Так что достаточно будет задать ParentColor = true (у многих это по умолчанию). Если же нужно, чтобы родительский элемент имел другой цвет, то, опять-же, я могу написать не рисующийся компонент, в который можно будет положить другие.
ну и ещё есть style sheetы
Если же нужно, чтобы родительский элемент имел другой цвет, то, опять-же, я могу написать не рисующийся компонент, в который можно будет положить другие.т.е. для того, чтобы группе контролов указать единый цвет (но при этот отличный от родительского) надо писать свой контрол? это такое преимущество dfm?
зы
кстати winforms хорош уже тем, что в нем эта проблема (что какие-то контролы более специальные) скрыта.
но для описания форм нужен мощный декларативный язык.назови хотя-бы пару use-case-ов, в которых для конструирования дизайна формы пригодятся переменные и if-ы.
Предполагаю, что для if-ов будет вариант "отображение различных элементов в зависимости от внешних условий и заранее отвечу на него: внешние условия, как правило, берутся из внешнего по отношению к дизайну формы кода, в связи с чем не вижу причины, по которой тот-же код не должен самостоятельно донастраивать сконструированную форму (помимо желания запихнуть всё что относится к View в код, описывающий форму).
ну и ещё есть style sheetыконкретно в D7 их нет
Хотя, наверное, есть какой-то набор компонентов, поддерживающий скины.
по которой тот-же код не должен самостоятельно донастраивать сконструированную форму (помимо желания запихнуть всё что относится к View в код, описывающий форму).чем это нагляднее? или о чем мы вообще говорим?
назови хотя-бы пару use-case-ов, в которых для конструирования дизайна формы пригодятся переменные и if-ы.все use-case с любыми зависимостями между контролами (цвет одного, как цвет другого; высота одного, как ширина другого и т.д.)
все тот же use case: сделать чтобы все кнопки внутри mypanel были одного цвета (или все то, что в html-е делается через css)
при наличии binding-ов - без переменных совсем не обойтись
назови хотя-бы пару use-case-ов, в которых для конструирования дизайна формы пригодятся переменные и if-ы.вот, например
<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage<IEnumerable<MvcApplication1.Models.Movie>>" %>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
<h2>Index</h2>
<table>
<tr>
<th>Id</th>
<th>Title</th>
<th>Director</th>
<th>DateReleased</th>
</tr>
<% foreach (var item in Model) { %>
<% Html.RenderPartial("MovieTemplate", item); %>
<% } %>
</table>
</asp:Content>
http://www.asp.net/learn/mvc/tutorial-11-cs.aspx
т.е. для того, чтобы группе контролов указать единый цвет (но при этот отличный от родительского) надо писать свой контрол? это такое преимущество dfm?в данном случае, этот dummy-контрол расширит возможности dfm. Хотя, скорее всего, этого явно не предусматривали специально при создании Delphi. В общем-то, к такому control'у следует относиться как к div'у в html-e, включаемому в другой div лишь за тем, чтобы поменять что-то внутри.
зыНе совсем понял, о чём ты. Какие контролы в Delphi более специальные? В базовом комплекте Delphi нет никаких "более специальных" контролов. Из принципиальных преимуществ WinForms я заметил поддержку всеми компонентами возможности настраивать различные свойства из xml-файла (кстати, реализация поддержки этого дела для C++/CLI корявая: чтобы прочитать параметры подключения к БД, нам пришлось ручками дописывать чтение нужных свойств и пробег по всем компонентам, работающим с БД - кстати, ещё один FAIL в Delphi принято иметь один компонент, задающий параметры БД, а к нему уже табличные компоненты, что гораздо ближе к описываемому тобой идеалу). Далее, D7 вышла в 2002м году (хотя значительная часть технологий появилась гораздо раньше). WindowsForms разработали значительно позже и естественно, что там будут некоторые новые возможности. Но самое интересное, что для покрытия этих дополнительных возможностей, я могу написать невизуальный компонент, который будет достаточно положить на форму и настроить. Конечно, дизайнер не покажет дополнительных свойств в каждом из компонент, но это уже придирки (и потом, подобные вещи удобнее настроить в одном месте, а не тыкаться по каждому компоненту на форме). Учитывая это, указанное выше преимущество WinForms не является таким принципиальным (плюс лишь в том, что данная фича идёт "из коробки").
кстати winforms хорош уже тем, что в нем эта проблема (что какие-то контролы более специальные) скрыта.
Не совсем понял, о чём ты. Какие контролы в Delphi более специальные?специальные они в windows-е, win forms делает их не специальными.
насколько я тебя понял, delphi так же как и mfc для спец. контролов требует спец. код, вместо того, чтобы просто менять поле background
чем это нагляднее? или о чем мы вообще говорим?Хочешь нагляднее - положи компонент подобный PageController на форму и выбирай отображаемую страницу.
Хочешь нагляднее - положи компонент подобный PageController на форму и выбирай отображаемую страницу.почему и зачем эти фишки не умеет декларировать сам язык форм?
зачем для этого надо на каждый чих писать какие-то dummy-контролы?
насколько я тебя понял, delphi так же как и mfc для спец. контролов требует спец. код, вместо того, чтобы просто менять поле backgroundА, ты о кнопках. Нет, в Delphi ты просто добавляешь в пакет dclusr компонент-кнопку, умеющую рисовать себе другой фон, и радуешься. От WinForms отличается необходимостью предварительной настройки среды. Скорее всего, где-то в инете этот компонент лежит.
зачем для этого надо на каждый чих писать какие-то dummy-контролы?я предлагаю решение, позволяющее этот язык расширить. Не обязательно даже помнить, что это контролы, назовём их просто группами. Твой вопрос напоминает вопрос "зачем в стандартной библиотеке шаблонов С++ под каждый вид контейнера свой шаблонный класс написан вместо определения специальных конструкций языка?".
Твой вопрос напоминает вопрос "зачем в стандартной библиотеке шаблонов С++ под каждый вид контейнера свой шаблонный класс написан вместо определения специальных конструкций языка?".нет, это вопрос вида - зачем было придумывать какой-то там C++, если все тоже самое можно было сделать на C - но с костылями.
или зачем сейчас везде делают конструкцию foreach если она прекрасно делается через for?
зачем сделали generic-и?
ps
подсказка: есть ряд вещей, которые плохо решаются без поддержки языка.
<% foreach (var item in Model) { %> <% Html.RenderPartial("MovieTemplate", item); %> <% } %>Для случая, если то, что внутри цикла, рисует, например, какие-то данные из набора, в Delphi есть готовая реализация. Если же ты на основе каких-то сгенерированных данных (при этом, тебе не нужно даже думать о том, что это цикл - ты просто создаёшь дизайн ). Большинство остальных случаев, по сути, сводятся к этому: если ты выводишь некий массив данных или запрашиваешь этот массив, значит логично говорить о наборе данных.
Ну, если не забывать, что задачи языка описания дизайна в десктопном приложении, разрабатываемом в RAD-системе, ограничиваются первоначальной загрузкой и инициализацией свойств всех компонент формы (или другого базового контейнера набор возможностей, который позволит решить все задачи на данном участке, не такой уж широкий (в случае веб-приложений, данный процесс происходит при каждом запросе на выдачу страницы, а в десктопном приложении загрузка и инициализация происходит либо при старте, либо, например, при создании формы MDI-клиента).
Ну, если не забывать, что задачи языка описания дизайна в десктопном приложении, разрабатываемом в RAD-системе, ограничиваются первоначальной загрузкой и инициализацией свойств всех компонент формы (или другого базового контейнера набор возможностей, который позволит решить все задачи на данном участке, не такой уж широкий.почему выбраны именно эти рамки?
почему выбраны именно эти рамки?Потому, что оффтопное обсуждение, которое я начал, было первоначально именно про RAD-системы и десктопные приложения. И я не нашёл пока достаточно убедительных доводов на вопрос о том, почему RAD-система не должна компилировать настройки компонент, заданных в design-time, в отдельном формате (с использованием легко парсящегося декларативного языка, компилируемого в байт-код для загрузки в run-time.
заданных в design-time, в отдельном формате (с использованием легко парсящегося декларативного языка, компилируемого в байт-код для загрузки в run-time.pickle?
И я не нашёл пока достаточно убедительных доводов на вопрос о том, почему RAD-система не должна компилировать настройки компонент, заданных в design-time, в отдельном формате (с использованием легко парсящегося декларативного языка, компилируемого в байт-код для загрузки в run-time.мне не нравится подразумеваемая тобой цель, т.к. я не вижу ее целесообразности.
я согласен, что для описания интерфейса удобен декларативный подход - и поэтому желательно для этого иметь мощный декларативный язык.
но я вообще не понимаю задачи: начальная загрузка настроек, и необходимости доп. языка для этого.
я вот вообще не понимаю зачем php, когда есть nasm?
я вот вообще не понимаю зачем php, когда есть nasm?ты это к чему?
просто так. Этот факт до сих пор вызывает моё удивление. Ведь как быстрее работали бы веб-странички, если бы были написаны на правильном языке
просто так. Этот факт до сих пор вызывает моё удивление. Ведь как быстрее работали бы веб-странички, если бы были написаны на правильном языкезабываешь про человеческий фактор.
веб-сайты клепает каждый второй - квалификация низкая: поэтому php, а не nasm
Оставить комментарий
Andbar
Кстати... Заметил два способа описания интерфейса в RAD-системах гуистроения: в виде данных некого формата, которые читаются, разбираются и по ним конструируются и настраиваются объекты; и в виде кода. При чём в первом случае форматы могут быть разные (лично я считаю, хранение xml-я в бинарнике при такой задаче нецелесообразным, как минимум, он должен компилироваться во что-то более просто разбираемое машиной во втором случае где-нибудь в исходниках образуется дико длинная функция с настройкой всех графических элементов, при этом весь этот код для работы дизайнера приходится каждый раз разбирать, что порой вызывает жуткие тормоза (мой личный опыт ограничивается сравнением дизайнеров от D7 и VS2005, так что я могу быть не прав). Минус хранения дизайна формы в ресурсах - более медленный запуск, т.к. приходится разбирать имена и искать адреса конструкторов классов и свойств и необходимость продвинутого RTTI, что немного повышает размер бинарника. Так как создание форм происходит сравнительно редко, этот минус несущественный.В общем, мне не очень понятно, почему в большинстве современных RAD-системах гуистроения применяется описание интерфейса в виде кода.