Правильно разделять представление и бизнес логику.

нет, ну конкретнее, как быть в той ситуации?

Мне, например, нравится, как это сделано у Apple:

1.


http://www.youtube.com/watch?v=_KAtEK7j06Y

2.


http://www.youtube.com/watch?v=MIo5EF2zDBY

Что ты подразумеваешь под "конкретнее", ты хочешь код что ли?

Ты хочешь сказать, что всё нужно делать в коде? И не заниматься "компонентомкидательством" на форму?

Если ты делаешь действительно сложный гуй - то да.
Вообще по хорошему действие и его вызов из гуя должны быть настраиваемыми. Т.е. мы можем повесить хоткей на некое действие, можем добавить кнопку на тулбар, или создать свое главное или контекстное меню, куда добавить это действие. Плюс плагины тоже должны создавать свои действия и так же прозрачно их встраивать в приложение.

Акелла правильно кивнул на TAction. Он именно этим и занимается. Ввели, емнип в еще 5й делфе.

Ты создаешь действие, потом рефаешь его из менюхи, туллбара, кнопы, попапа. Ты можешь управлять иконами, видимостью, доступностью, описанием экшна как из кода реализующего некую логику, так и декларативно, описав обработчик события обновления статуса экшна. Визуальные контроллы, для которых назначен экшн будут обновляться в соответствии с его настройками.

Всамделе - бомба вещь.  

Это сообщение отредактировал(а) Zloxa - 17.5.2012, 14:29

Не правда. Сложный гуй проще сделать в дизайнере, потому как у тебя нервов не хватит каждый раз запускать проект, дабы передвинуть контрол на пиксель в лево, потомы что он почему-то совсем не смотрится. Уже давно люди поняли, что гуй десктопных приложений нужно делать в дизайнере, только явистам это пока не всем дошло. Ну так вы посмотрите и на программы, написанные на яве.
В обработчике Button1OnClick можно создать класс, который вызовет один единственный метод, вот и всё. Ну и конечно там можно писать всё, что касается гуя.
Если вы не согласны, что сложный гуй можно сделать в дизайнере, то скажите, много ли вы знаете насколько динамичных гуев, который сложно сделать размещением компонентов на форму? Вокруг меня: хром, ворд, тоталкомандер, скайп и тд. не помню программы, где гуй каждую секунды с ног на голову переворачивается.
А вот, что касается размещения на форме Не визуальных компонетов, и не имеющих отношения к гую - это, простите, быдлокод.

ivanfain, бред.
Полностью не согласен.

Тут согласен. Процесс ручного фомрирования километровых XML конфигов - дает куда большее удовлетворение и яркий экстаз, если это наконец заработает.   

И в результате получаем гуй состоящий из нагромождения контролов и который может работать в одном разрешении экрана.

Наверное ты не о разрешении а об коэффиценте увеличения(не знаю как по русски, scalling), которое устанавливается в настройках винды. Тут конечно да, жава срала на эти настройки гуеоса, и при их любых настройках выглядит одинаково. В делфе у формы есть свойство, определяющее подобное поведение. Действительно жаль что оно всегда по умолчанию отключено.

Нет именно про разрешение. Если компоненты выравниваются попиксельно, то ни о каком изменении размеров окна и речи не идет.

Есть крюки (емнип, называются anchos), которые можно определить для визуального компонента и сразу же проверить, в дизайнере, как это будет работать при растягивании/сжатии формы. Появилась плюшка не сразу. Кажись в седьмой делфе, возможно в пятой. Раньше резиновые формы приходилось делать панелями. Чуть менее удобно, но куда удобнее, нежели лапами кодить.

Для конфигурирования xml обычно делают визуальные дизайнеры, а вот конфигурировать его в презентационном слое приложения... ну вы понимаете... не самое лучшее место.


  

Всё решается, разрешение экрана уже давно не является страшной проблемой при визуальном проектировании приложения. Тем более, никто не запрещает и с кода какие-то элементы подвинуть. Другое дело полностью на mvc приложение делать. В общим у кого нету опыта с обоими юзезкейсами, тому не понять.