Как стать автором
Обновить

Комментарии 53

'штука для создания карт' — может штука для создания макетов?
Спасибо за статью. Akshell тоже сделан на Cappuccino?
Да. Я решил поделиться позитивным опытом.
Отдельное спасибо за Akshell
Пожалуйста :)
Выбирал недавно как раз фреймворк для web gui, Cappuccino тоже смотрел, но мне показалось, что именно удобен он будет тем кто писал под Mac OS, других программистов слезающих с JQuery, Prototype и ОО JavaScript будет только сковывать.

зы. в итоге выбрал ExtJS, не жалею.
Я под Mac не писал, выбрал Cappuccino из-за красивого внешнего вида и под впечатлением от 280 Slides. Только в процессе использования понял, что Cocoa API – это очень круто.
Видимо мне просто не хватило времени, понял что изучать новый почти язык над JS нет времени и решил, что ExtJS мне всё прозрачнее показывает.
Удивительно, но все, кто использует objective-c тоже так говорят — сначала кажется неудобным, но когда распробуешь, понимаешь, насколько круто:)

Странно, что некоторые функции выглядят не по objective-c — я про круглые скобки:

var window = [[CPWindow alloc] initWithContentRect:CGRectMake(100, 100, 250, 70)
CGRectMake – обычная JavaScript функция. Это тоже скопировано с Cocoa, там CGRectMake – обычная C-шная функция.
Я человек далекий от веб программирования. Но я так понял, что такие сложности нужны только для того, чтобы не нужно было ставить дополнительных компонент для браузеров? Типа Silverlight, Java, Flash и т.д.?
Чтобы переварить Objective-J код в html + css + js. На мой взгляд, затея не очень. Внешний вид – возможно.
Честно говоря, никогда не использовал эти технологии. Сложности Cappuccino связаны прежде всего с его мощностью: приложения могут использовать полноценную MVC архитектуру, за счет этого можно строить очень функциональные интерфейсы пользователя. Т.е. сложность изучения на начальном этапе окупает себя в дальнейшем.
Ну под Silverlight и не такое можно. Там используется C# и подмножество .NET Framework. Можно использовать хоть MVC, хоть MVVM, хоть напрямую к визуальному дереву обращайся. Плюс там много продвинутых фишек, позаимствованных из WPF — Data Binding, стили и шаблоны, Dependency Property и много чего еще, облегчающего управление поведением визуального дерева. Ну и недостатки есть конечно.
Все эти вещи, наверняка, очень мощны, но требуют изучения так же, как Cappuccino. В Cappuccino тоже есть продвинутые фишки, не описанные в очерке, например, Key-Value Binding (судя по названию, это аналог Data Binding). Думаю, что с WPF проще перейти на Silverlight, с Cocoa – на Cappuccino.

Большим плюсом Cappuccino по сравнению с Silverlight является то, что он не требует ничего, кроме современного браузера.
Этакий привет GWT.
А представление о Cocoa по этой вещи получить реально?
Конечно, я активно пользовался эппловской документацией – Cappuccino реализует большую часть API Cocoa.
К слову, в опере не пашет. Вот вам и кроссбраузерность.
хм, странно. у меня в опере заработало
Что именно не заработало в опере?
Ну во первых Your browser isn't supported.
Если в быстрых настройках замаскировать под firefox, то открывается, но ничего напечатать нельзя.
Видимо, речь идет про Akshell, а не про учебный пример. Опера не поддерживается не из-на Cappuccino, а из-за Mozilla Skywriter, текстового редактора. В ближайшее время я переведу Akshell на его наследника ACE, тогда все браузеры будут поддерживаться.
Вообще Cappuccino поддерживает все браузеры. Например, gomockingbird.com/ работает в опере, я проверил. У просто у меня стояла не релизная версия фреймворка, а просто выкачанная из master, обновляться я поленился. Думаю проблема в этом, с Cappuccino 0.9 все должно работать отлично.
При компиляции кода Cappuccino в JavaScript мы получим совершенно другой код. Полученный код будет не наш, мы не сможем его эффективно отладить как мы сможем отладить чистый JavaScript (будем отлаживать не то, что писали) это как писать на C, а отлаживать машинные команды в asm. Плюс ко всему из-за обертки над DOM JS CSS мы теряем контроль над конечным результатом и поэтому мы не сможем оптимизировать. Такая же проблема с CoffeeScript
В принципе, компиляция Objective-J не такой уж хитрый процесс, самое главное, что в нем происходит – это замена отсылки сообщений через синтаксис квадратных скобок на вызовы функции objj_msgSend с соответствующими параметрами. Т.е. Cappuccino приложения вполне можно отлаживать в Firebug, мне приходилось. Не слишком удобно, конечно, но возможно.

Если требуются оптимизация или прямой доступ к DOM, в Cappuccino нужно создавать кастомный контрол и писать код на JavaScript. Контролы самого Cappuccino так и реализованы. Еще можно просто создать iframe.

Ну а потеря контроля над конечным результатом – следствие любой абстракции. Просто для многих приложений это приемлемо.
Удручает практически полное отсутствие hover-эффектов. Ни в Mockingbird, ни в 280slides не заметил. Хоть бы курсор менялся при наведении.
Это называется осознанным проектированием интерфейса.

О чем сообщает hover-эффект? О том что курсор над объектом. Но мы же только что сами его туда передвинули, зачем об этом дополнительно сообщать?

Такие эффекты нужны только в ситуациях, когда курсор находится над объектом, от которого мы не ожидаем интерактивности.

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

P. S. Дизайнеры интерфейса виндоус, наверное, не догадываются о таких вещах.
Не согласен.

Возможно, это субъективное мнение, но интерфейс с hover-эффектами выглядит куда более отзывчивым и «живым», располагает к тому, чтобы с ним работали. Как правило, именно изменение внешнего вида при наведении намекает мне на то, что от этого объекта можно ожидать интерактивности: активная кнопка при наведении подсвечивается, а неактивная остается такой же.

И причем тут вообще «дизайнеры интерфейса виндоус»? Курсор с ручкой при наведении на ссылку тоже они придумали?
Почему какие-то эффекты должны намекать, что я могу нажать на кнопку? Разве кнопки не предназначены для того, чтобы на них нажимать?

Неактивные кнопки просто делают блеклыми (прозрачными, неконтрастными).

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

Интерфейс — это всегда помеха. Это то, что стоит между мной и тем, что я хочу сделать. И чем он более «живой», мигающий и т. п., тем больше он перетягивает на себя моего внимания. И если уж интерфейс мигнул, значит у него на то должна быть веская причина, потому что для программы не должно быть ничего важнее чем моя работа.
Тогда почему в контекстном меню элемент под мышкой-таки подсвечивается? Разве он не предназначен для того, чтобы его нажимали?
Потому что это не кнопка, а просто надпись, и ее нажимабельность не очевидна.

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

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

А если функция обучающая, тогда человек может с равной вероятностью не знать, что можно нажимать на пустое место рядом с пунктом меню или на кнопку. И вообще, кнопка в своем классическом понимании должна быть хотя бы выпуклой, что-ли. Картинка с текстом, никаким образом не выделенная и не подсвечивающаяся при наведении, очень субъективно напоминает что-то нажимаемое.
Подсветка помогает понять, какому пункту меню принадлежит пустое место, на которое мы кликаем. Т. е. так намного легче целиться, иначе, чтобы точно не промахнуться, мы бы всегда нажимали на текст.

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

Картинка с текстом на тулбаре — это тоже соглашение из макоса. Здесь такие картинки всегда интерактивны. После нескольких минут работы человек привыкает, и отпадает необходимость в лишних сигналах.
Дело в том, что ожидание hover'ов на веб-страницах уже настолько выдрессировано в нас, что ничего нельзя поделать. К тому же сколько бы близко веб-страница не приближалась к десктопному приложению, ощущение, что «это — браузер» и «это — страница» лично меня не покидают, поэтому хочется hover'ов!:)

Да и просто приятно, когда элемент немного подсвечивается.
Мне кажется, что здесь сыграли свою роль и виндоус с линуксом. У меня после макоса подобных ощущений не возникает. Этому, конечно же, помогает и то, что все контролы скопированы отсюда :)
откройте для себя SproutCore. то же самое, но без издевательств над Javascript'ом
korenyushkin.github.com/
При вводе буквы в поле поиска фокус из поля пропадает, приходится щелкать в него и писать следующую букву.
Опера 11.01.
Да, проблема, вероятно, в том, что я взял нестабильную версию фреймворка. Вообще Cappuccino поддерживает все основные браузеры.
korenyushkin.github.com/twitter-search/
Скролл в окне дико тормозит в ИЕ8. Фактически пользоваться колесом мышки нереально, да и перетаскивать ползунок проблематично.
Да, у Cappuccino пока есть проблемы со скроллингом в некоторых браузерах. Возможно, в новой версии это пофиксили.
А можно я вас задолбаю вопросами в личку о Cappucino? Я давно хотел его начать использовать, но никак не мог найти годную документацию с примерами (спасибо, что сказали о том, что документация от apple подходит). Вот первый вопрос — как вы реализовали авторизацию в своем проекте? А то у меня маленько не получается перенести cocoa (я под ios пишу) в браузер.
Конечно, можно :)

Авторизация реализуется через Cookies, она обрабатывается на стороне сервера, т.е. клиентский код с ней дела почти не имеет. Единственное, что от него требуется – это отобразить имя пользователя, оно ему передается как глобальная JavaScript переменная, объявленая в HTML файле.
А как клиент с сервером связывается? JSON/XML-RPC? Я сейчас просто пишу сервис где надо будет постоянно обмениваться с сервером информацией по средством json и отображать полученную информацию (например адресная книга), надо иметь возможность изменить информацию и отправить апдейт на сервер (в виде json). Я вот думаю на чем лучше это реализовать.
Клиент опрашивает сервер с помощью XMLHttpRequest, данные передаются в формате JSON. Но можно любой формат использовать, для Cappuccino это не важно. Для XMLHttpRequest'а и для JSONP в Cappuccino есть удобные «обертки».
А кастомизиция/темизация интерфейса какая-нибудь предусмотрена? Уж очень непривычно выглядит тот, что в примерах.
Да, Cappuccino поддерживает темы. Но тема по умолчанию (Aristo) самая популярная и, на мой взгляд, самая симпатичная. Ее сделала дизайнерская фирма Sofa.
Один крестик слева может отпугнуть 90% юзеров…
спасибо и подскажите настолько он удобен для создания веб-приложений для iOS (например в случае не пропускания нативного приложения в appStore) и вдруг есть подводные камни.
Боюсь, тут я помочь не смогу – нет опыта. Но я помню, что эти вопросы обсуждались в группе Cappuccino, попробуйте поискать там.
Огромное спасибо за статью! Хочу отметить, что у вас хороший слог: читается на одном дыхании
Всегда пожалуйста, спасибо за комплимент :)
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации