Здравствуйте, Cyberax, Вы писали:
D>>Ну так что это за аналоги-то ? Я вот лично таких не знаю. Есть вещи в которых присутствуют разные отдельные куски идей стоящих за XAML, но чтобы всё это было грамотно сведено в одном месте — такого не припоминаю. C>Их много разных: http://java-source.net/open-source/xml-user-interface-toolkits — есть и с возможностью байндинга отдельных свойств.
Мне не нужны "много разных" наколенных студенческих поделок. Покажите аналог XAML, то бишь нормальную production quality библиотеку сериализации поддерживающую все концепции XAML. Достаточно "одной штуки".
C>>>Она не отделена в WinForms и других подобных фреймворках. Скажем, в WinForms текстовое поле просто содержит строку, которую ты берёшь как "ctrl.Text". D>>И в Swing'е всё ровно также: getText() и телемаркет. C>Это не более чем удобный аксессор.
Отличный комментарий! "Удобный"
D>>Так это не та модель. Это модель элемента UI. А точнее её часть, бо его остальные ~100 свойств в неё почему-то не входят. И зачем оно нужно ??? C>За большую часть остальных свойств отвечает: C>1) Система layout'ов, внешняя по отношению к контролу. C>2) Look&Feel.
Ещё раз повторяю: мне не нужны "много разных" expression engine'ов. Мне нужен binding модели данных приложения к элементам UI Swing'а, с поддержкой выражений, и корректно интегрированный.
D>>Ну занимается. Ну может меняться. Да, жизнь разработчиков Swing Team из Sun, видимо, облегчилась. Может ещё каким героям скиноваяния тоже стало чуть веселее. А вот мне, как обычному разработчику, совершенно по-барабану. Бо подход к рендерингу UI при этом совершенно не изменился. И написать свой look&feel к Swing'у, даже для пары control'ов, это куча работы. Тогда как заскинить control в WPF не представляет никаких затруднений. Более того, для этого в большинстве случаев я даже практически не нужен. Всё может сделать и непосредственно дизайнер.
C>Специально для тебя сделали skinnable L&F'ы...
О да-а-а!!! Synth и его border'ы на картинках. Мегатехнология каменного века. И Вы эту ерунду пытаетесь выдать за WPF power ??? Или Вы о каком-то другом "представителе семейства" ???
C>JavaFX они варили достаточно долго, аж с 2004-го года.
Про то и говорю. WPF начали показывать ещё в 2003.
C>Оно больше как конкурент Silverlight/Flash.
Дык одно другому не мешает. Конкуренты Silverlight/Flash на J2ME-платформах. Desktop'ы там пока что только ради расширяемости и "униформности".
C>>>Лучше явно выделять такие сервисы в сервисные классы. D>>Они и так выделены. Extension-методы есть методы статических классов. Если Вас напрягает instance-ный синтаксис вызова, то Вы можете вызывать их и обычным образом. C>Если вызывать обычным способом — то они и не нужны.
Неправда. Это позволяет без проблем пользоваться библиотечными extension-методами не только нормальным людям, понимающим зачем они нужны, но и всяким пуристам от ООП вроде Вас
Здравствуйте, Cyberax, Вы писали:
C>Нельзя было использовать AD (я же написал, что оно должно было работать параллельно с AD). Ты думаешь, мы такие тупые, что не догадались бы воткнуть схему в AD и наслаждаться жизнью?
Тогда я не понимаю значение слова "параллельно" — если в смысле "одновременно с", то расширение схемы — то, что доктор прописал. Не опишешь поподробнее? (не флейма ради — мне просто интересно, плюс потенциально полезно)
Здравствуйте, drol, Вы писали:
C>>Их много разных: http://java-source.net/open-source/xml-user-interface-toolkits — есть и с возможностью байндинга отдельных свойств. D>Мне не нужны "много разных" наколенных студенческих поделок. Покажите аналог XAML, то бишь нормальную production quality библиотеку сериализации поддерживающую все концепции XAML. Достаточно "одной штуки". http://xul.sourceforge.net/counter.html — там немного другие концепции, такой же ТОЧНО — нет.
C>>Это не более чем удобный аксессор. D>Отличный комментарий! "Удобный"
Ну да. Не писать же каждый раз:
(именно так getText() и реализован).
C>>2) Look&Feel. D>А мне-то (как пользователю Swing'а) какое до этого дело ??? Для визуализации модели данных приложения используется весь спектр свойств элементов UI — цвета, размеры, положение, шрифты и т.д. Так вот ещё раз повторяю вопрос. Зачем часть (очень малая) свойств элементов UI "отпилена" в отдельную иерархию интерфейсов ???
Выделена отдельная часть, связанная с выдачей данных. Всё что связано с общим стилем контрола — управляется внешними системами. Нормальное разделение, на самом деле.
C>>Это всё есть в SWING'е, даже брожение по дереву контролов с помощью декларативного языка — http://www.opensymphony.com/ognl/html/LanguageGuide/introduction.html или http://commons.apache.org/jxpath//users-guide.html#Nested_Bean_Property_Access D>Неправда. Ни OGNL, ни JXPath в Swing'е нет.
Они отдельно есть
D>Ещё раз повторяю: мне не нужны "много разных" expression engine'ов. Мне нужен binding модели данных приложения к элементам UI Swing'а, с поддержкой выражений, и корректно интегрированный.
Вот час назад только написал: "context.setValue("root_panel//checkbox[@weekday='tuesday']",true);"
В смысле — делается binding при желании. Готового полностью юзабельного нет, но для самоделок полно решений.
C>>Специально для тебя сделали skinnable L&F'ы... D>О да-а-а!!! Synth и его border'ы на картинках. Мегатехнология каменного века. И Вы эту ерунду пытаетесь выдать за WPF power ??? Или Вы о каком-то другом "представителе семейства" ???
А что такое Synth? Я больше про http://www.l2fprod.com/skinlf/converter/index.php
C>>Оно больше как конкурент Silverlight/Flash. D>Дык одно другому не мешает. Конкуренты Silverlight/Flash на J2ME-платформах. Desktop'ы там пока что только ради расширяемости и "униформности".
Они сейчас заняты тем, что все платформы стараются унифицировать.
Здравствуйте, koandrew, Вы писали:
C>>Нельзя было использовать AD (я же написал, что оно должно было работать параллельно с AD). Ты думаешь, мы такие тупые, что не догадались бы воткнуть схему в AD и наслаждаться жизнью? K>Тогда я не понимаю значение слова "параллельно" — если в смысле "одновременно с", то расширение схемы — то, что доктор прописал. Не опишешь поподробнее? (не флейма ради — мне просто интересно, плюс потенциально полезно)
Оно должно работать на прикладных компьютерах как "прокси" для AD, добавляя лишнее дерево в его лес (либо вообще автономно, если AD не используется).
Здравствуйте, Cyberax, Вы писали:
D>>Отличный комментарий! "Удобный" :)) C>Ну да. Не писать же каждый раз:
... C>(именно так getText() и реализован).
Конечно не писать. Мне в WPF вообще почти никогда не приходится писать m_someGuiControl.Text. Более того, я даже имён контролам не даю, потому что из кода к ним не обращаюсь. В своём коде я использую ViewModel.MyPropertyWithMeaningfulName, а его значение устанавливается байндингом, который декларативно описывается в XAML'е.
Ещё раз, во фреймворке с богатыми средствами байндинга тебе никогда не придётся делать вызов типа someTextBox.getText(), тебе даже не обязательно знать имя того или иного контрола, один раз указал привязку и забыл.
C>>>Это не более чем удобный аксессор.
Самый удобный аксессор это тот, который тебе не приходится вызывать.
Здравствуйте, Cyberax, Вы писали:
C>Оно должно работать на прикладных компьютерах как "прокси" для AD, добавляя лишнее дерево в его лес (либо вообще автономно, если AD не используется).
Ну так это можно (и ИМХО нужно) было сделать с помощью ADSI-экстеншена, который нужно будет проинсталлить на целевые машины. Или я опять чего-то не знаю/не понимаю? Можете пояснить на примере? Как я понимаю задачу:
есть дерево
Здравствуйте, koandrew, Вы писали:
C>>Оно должно работать на прикладных компьютерах как "прокси" для AD, добавляя лишнее дерево в его лес (либо вообще автономно, если AD не используется). K>Ну так это можно (и ИМХО нужно) было сделать с помощью ADSI-экстеншена, который нужно будет проинсталлить на целевые машины. Или я опять чего-то не знаю/не понимаю? Можете пояснить на примере? Как я понимаю задачу:
Оно должно работать и без AD вообще.
K>есть дерево
Вам нужно заставить клиентов думать, что есть ещё dc=virtualdomain,dc=forest, dc=com. Так чтоли?
Вообще отдельное дерево (с предопределённым именем) типа "ou=somename, dc=blah".
Здравствуйте, Qbit86, Вы писали:
C>>(именно так getText() и реализован). Q>Конечно не писать. Мне в WPF вообще почти никогда не приходится писать m_someGuiControl.Text. Более того, я даже имён контролам не даю, потому что из кода к ним не обращаюсь. В своём коде я использую ViewModel.MyPropertyWithMeaningfulName, а его значение устанавливается байндингом, который декларативно описывается в XAML'е.
А байндинг данные откуда берёт? Из свойства с именем "MyPropertyName"?
Q>Ещё раз, во фреймворке с богатыми средствами байндинга тебе никогда не придётся делать вызов типа someTextBox.getText(), тебе даже не обязательно знать имя того или иного контрола, один раз указал привязку и забыл.
Ну это сказки даже в WPF, особенно если нужно делать хитрую логику.
PS: конкретно для байндинга я себе собираюсь прикрутить систему линз из Augeas'а (переписанную и адаптированую). Всякие WPFы будут лежать в глубоком осадке.
Здравствуйте, Cyberax, Вы писали:
Q>>Ещё раз, во фреймворке с богатыми средствами байндинга тебе никогда не придётся делать вызов типа someTextBox.getText(), тебе даже не обязательно знать имя того или иного контрола, один раз указал привязку и забыл. C>Ну это сказки даже в WPF, особенно если нужно делать хитрую логику.
0_o Да что ты говоришь! Эта сказка называется «паттерн MVVM», смотри, например, презентацию (100 Мб) Джейсона Долинджера, особенно обрати внимание на окрестности момента времени 00:21:44:
You are on the right track when you almost NEVER have a need to name a control with x:Name.
Ну что, объясни мне, что заставляет тебя раз за разом упрямо демонстрировать свою недалёкость, кичиться некомпетентностью в вопросах, в которых ни черта не смыслишь?
C>Ну это сказки даже в WPF, особенно если нужно делать хитрую логику.
Хитрая логика работает с моделью вида, а не с гуёвыми контролами.
C>А байндинг данные откуда берёт? Из свойства с именем "MyPropertyName"?
При создании байндинга ему указывается source — ViewModel.MyPropertyName, само свойство является target'ом (например, Text элемента myTextBox), направление привязки (←, →, ⇄), плюс конвертер (если нужен). Всё, после этого о someControl.getText() можно забыть.
C>Всякие WPFы будут лежать в глубоком осадке.
Учитывая твой уровень владения матчастью, «глубокий осадок» вполне мог бы рассмешить. Если бы меня не печалило подобное навязчивое бравирование невежеством.
Здравствуйте, Qbit86, Вы писали:
Q>0_o Да что ты говоришь! Эта сказка называется «паттерн MVVM», смотри, например, презентацию (100 Мб) Джейсона Долинджера, особенно обрати внимание на окрестности момента времени 00:21:44:
You are on the right track when you almost NEVER have a need to name a control with x:Name.
Ну что, объясни мне, что заставляет тебя раз за разом упрямо демонстрировать свою недалёкость, кичиться некомпетентностью в вопросах, в которых ни черта не смыслишь?
Ключевое слово здесь "almost", обрати на него внимание.
C>>Ну это сказки даже в WPF, особенно если нужно делать хитрую логику. Q>Хитрая логика работает с моделью вида, а не с гуёвыми контролами.
Что получается одно и то же, если нужно делать хитрые визуальные действия.
C>>А байндинг данные откуда берёт? Из свойства с именем "MyPropertyName"? Q>При создании байндинга ему указывается source — ViewModel.MyPropertyName, само свойство является target'ом (например, Text элемента myTextBox), направление привязки (←, →, ⇄), плюс конвертер (если нужен). Всё, после этого о someControl.getText() можно забыть.
Это я к тому, что имя объекта можно банально генерировать (как я и делаю, кстати).
C>>Всякие WPFы будут лежать в глубоком осадке. Q>Учитывая твой уровень владения матчастью, «глубокий осадок» вполне мог бы рассмешить. Если бы меня не печалило подобное навязчивое бравирование невежеством.
Я прекрасно знаю как работает WPF, так как я его использовал. У меня будет лучше.
Здравствуйте, Qbit86, Вы писали:
C>>Я прекрасно знаю как работает WPF, так как я его использовал. Q>Ой, перестань. Ты уже демонстрировал своё «прекрасно знаю».
И таки ни одной моей ошибки ты не указал...
Здравствуйте, Qbit86, Вы писали:
C>>И таки ни одной моей ошибки ты не указал... Q>Самовнушение как неприятие реальности? Мои комментарии выше от этого никуда не денутся.
Ну так показывай конкретно ошибки. Я использовал WPF — байндинг мне оттуда понравился, всё остальное не особо впечатлило. SWING тут мало кто использовал, так что критика часто совсем не по делу.
Здравствуйте, Cyberax, Вы писали:
C>>>И таки ни одной моей ошибки ты не указал... Q>>Самовнушение как неприятие реальности? Мои комментарии выше от этого никуда не денутся. C>Ну так показывай конкретно ошибки. Я использовал WPF — байндинг мне оттуда понравился, всё остальное не особо впечатлило. SWING тут мало кто использовал, так что критика часто совсем не по делу.
Да ошибок то как таковых нет, но то, что ты пишешь уж больно напоминает типичное поведение людей, которые, столкнувшихся с WPF, решили не тратить время для серьезного изучения (такое же мы наблюдаем на форуме КСВ в отношении .Net вообще). Если пишешь на .Net, то единственной причиной отказа от WPF я могу понять необходимость наличия графики игрового уровня, тут WPF мало чем поможет, скорее даже помешает. Но всё остальное — это просто банальное нежелание осваивать одно, а взамен втащить какую-нить "адаптированную", но привычную стороннюю штуковину в проект.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Qbit86, Вы писали:
Q>>0_o Да что ты говоришь! Эта сказка называется «паттерн MVVM», смотри, например, презентацию (100 Мб) Джейсона Долинджера, особенно обрати внимание на окрестности момента времени 00:21:44:
You are on the right track when you almost NEVER have a need to name a control with x:Name.
Ну что, объясни мне, что заставляет тебя раз за разом упрямо демонстрировать свою недалёкость, кичиться некомпетентностью в вопросах, в которых ни черта не смыслишь? C>Ключевое слово здесь "almost", обрати на него внимание.
Этот вопрос уже обсуждали, "almost" появляется там, где нужно байндить между сосбой визуальные контролы.
При этом в коде обращений не будет.
C>>>Ну это сказки даже в WPF, особенно если нужно делать хитрую логику. Q>>Хитрая логика работает с моделью вида, а не с гуёвыми контролами. C>Что получается одно и то же, если нужно делать хитрые визуальные действия.
Не получается, все хитрые визуальные действия задаются в xaml, и свзяюваются триггерами (тоже в xaml).
C>>>Всякие WPFы будут лежать в глубоком осадке. Q>>Учитывая твой уровень владения матчастью, «глубокий осадок» вполне мог бы рассмешить. Если бы меня не печалило подобное навязчивое бравирование невежеством. C>Я прекрасно знаю как работает WPF, так как я его использовал. У меня будет лучше.
"Использовал" надо заменить на "видел".
Здравствуйте, gandjustas, Вы писали:
C>>Ключевое слово здесь "almost", обрати на него внимание. G>Этот вопрос уже обсуждали, "almost" появляется там, где нужно байндить между сосбой визуальные контролы. G>При этом в коде обращений не будет.
Тебе никогда не встречался случай, что байндинг имеет недостаточную мощность? У меня такие случаи попадаются постоянно. Я пока не знаю системы байндинга, которая была бы достаточно мощной для моих целей.
C>>Что получается одно и то же, если нужно делать хитрые визуальные действия. G>Не получается, все хитрые визуальные действия задаются в xaml, и свзяюваются триггерами (тоже в xaml).
Триггеры предназначены, прежде всего, для простых действий, типа установки фокуса в нужное место при нажатии или запуска анимации. У меня всё сложнее.
C>>Я прекрасно знаю как работает WPF, так как я его использовал. У меня будет лучше. G>"Использовал" надо заменить на "видел".
Нет, именно использовал. В первый раз ещё в 2007-м, если не ошибаюсь (до появления XAML-редактора).
Здравствуйте, gandjustas, Вы писали:
C>>Я прекрасно знаю как работает WPF, так как я его использовал. У меня будет лучше. G>"Использовал" надо заменить на "видел".
Кстати, мне тут бросили ссылку на XAML для Java: http://www.soyatec.com/eface/documentation/eFaceOverview/
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Ключевое слово здесь "almost", обрати на него внимание. G>>Этот вопрос уже обсуждали, "almost" появляется там, где нужно байндить между сосбой визуальные контролы. G>>При этом в коде обращений не будет. C>Тебе никогда не встречался случай, что байндинг имеет недостаточную мощность?
В WPF — нет. зато я знаю множество людей, которые не знают\не понимают возможностей байндинга в WPF.
C>У меня такие случаи попадаются постоянно. Я пока не знаю системы байндинга, которая была бы достаточно мощной для моих целей.
Может стоит повнимательнее изучить существующие?
C>>>Что получается одно и то же, если нужно делать хитрые визуальные действия. G>>Не получается, все хитрые визуальные действия задаются в xaml, и свзяюваются триггерами (тоже в xaml). C>Триггеры предназначены, прежде всего, для простых действий, типа установки фокуса в нужное место при нажатии или запуска анимации.
Это кто такую глупость сказал? Триггер может запустить Storyboard, а он в свою очередь может сделать парктически все.
C>У меня всё сложнее.
Также сложно как с embedded LDAP?
Мне кажется что вы очередной раз выдумываете сложности.
C>>>Я прекрасно знаю как работает WPF, так как я его использовал. У меня будет лучше. G>>"Использовал" надо заменить на "видел". C>Нет, именно использовал. В первый раз ещё в 2007-м, если не ошибаюсь (до появления XAML-редактора).
А последний?
