Альтернативные “архитектурные” подходы к клиентскому коду JavaScript?

MochiKit является большим - и был моей первой любовью, если можно так выразиться, насколько js библиотеки идут. Но я нашел, что, в то время как MochiKit имеет очень выразительный синтаксис, это не чувствовало себя почти так же комфортно для меня как Prototype/Scriptaculous, или jQuery сделал для меня.

я думаю, знаете ли Вы или как Python, тогда MochiKit является хорошим инструментом для Вас.

Поблагодарите всех любезно за свои ответы. Через какое-то время я хотел бы отправить то, что я изучил до сих пор.

До сих пор, я вижу очень значительные различия подход с помощью чего-то как Расширение , и другие как JQuery UI, Scriptaculous, MochiKit, и т.д.

С Расширением, HTML является просто единственным заполнителем - UI идет сюда. С тех пор все описано в JavaScript. Взаимодействие DOM минимизировано под другим (возможно, более сильный) уровень API.

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

существенные различия начинают происходить, поскольку я должен иметь дело с обработкой событий, и т.д. Поскольку модули должны "говорить" друг с другом, я должен для продвижения далеко от DOM, абстрагируя ее далеко в частях.

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

А новый плеер I приютов, полностью оцененных, Sproutcore. На Расширение в подходе, походит, где DOM скрыт, и Вы главным образом хотите иметь дело с API проекта.

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

я действительно видел одну попытку некоторое время назад, где кто-то создал платформу для моделирования данных в JavaScript, во многом как способ, которым SQLite принадлежит приложению. Это было похоже на Model.select ("продукт") и Model.update ("продукт", "Некоторые данные..."). Это была в основном объектная нотация, которая содержала набор данных для управления состоянием текущей страницы. Однако минута, которую Вы обновляете, все эти данные, потеряна. Я, вероятно, выключен на синтаксисе, но Вы понимаете.

при использовании jQuery, тогда подход Ben является действительно лучшим. Расширьте объект jQuery с помощью своих функций и свойств, и затем разделите свои "контроллеры". Я обычно делаю это путем помещения их в отдельные исходные файлы и загрузки их на основе раздела разделом. Например, если бы это был сайт электронной коммерции, у меня мог бы быть файл JS, полный контроллеров, которые обрабатывают функциональность для процесса контроля. Это имеет тенденцию сохранять вещи легкими и легкими справиться.

Просто быстрое разъяснение.

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

я записал приложения GWT, которые являются очень "MVC-выходом" на одной только стороне клиента.

• модель была графом объектов. Хотя Вы кодируете в Java во времени выполнения, объекты находятся в JavaScript без потребности любой JVM или в клиенте или в серверной стороне. GWT также поддерживает JSON с полной поддержкой парсинга и управления. Можно соединиться с веб-сервисами JSON легко, видеть 2 для примера мэшапа JSON.
• Представление состояло из стандартных виджетов GWT (плюс некоторые наши собственные составные виджеты)
• , уровень Controller был аккуратно разделен от Представления с помощью Шаблона "наблюдатель".

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

Не 100%, уверенных, что Вы имеете в виду здесь, но я скажу, что после выполнения ASP.NET в течение прошлых 6 лет, мои веб-страницы теперь главным образом управляются JavaScript, как только основной рендеринг страницы сделан сервером. Я использую JSON для всего (были в течение приблизительно 3 лет теперь), и используйте MochiKit для моих клиентских потребностей.

Между прочим, JavaScript OO, но так как это использует формирующее прототип наследование, люди не дают ему кредит таким образом. Я также утверждал бы, что это функционально также, все это зависит от того, как Вы пишете его. Если Вы действительно интересуетесь стилями функционального программирования, проверяете MochiKit - можно понравиться он; это вполне немного склоняется к стороне функционального программирования JavaScript.

JavaScriptMVC - отличный выбор для организации и разработки крупномасштабных JS-приложений.

Архитектурный дизайн очень хорошо продуман. Есть четыре вещи, которые вы когда-либо будете делать с помощью JavaScript:

1. Ответить на событие
2. Запросить данные / управлять услугами (Ajax)
3. Добавить информацию о домене в ответ ajax.
4. Обновление DOM

JMVC разделяет их на модель, представление, шаблон контроллера.

Первое и, вероятно, самое важное преимущество - это контроллер. Контроллеры используют делегирование событий, поэтому вместо присоединения событий вы просто создаете правила для своей страницы. Они также используют имя контроллера, чтобы ограничить объем работы контроллера. Это делает ваш код детерминированным, то есть если вы видите, что событие происходит в '#todos' вы знаете, что должен быть контроллер задач.

$.Controller.extend('TodosController',{
   'click' : function(el, ev){ ... },
   '.delete mouseover': function(el, ev){ ...}
   '.drag draginit' : function(el, ev, drag){ ...}
})

Затем идет модель. JMVC предоставляет мощный класс и базовую модель, которая позволяет быстро организовать функциональность Ajax (№2) и обернуть данные специфичными для домена функциональными возможностями (№3). По завершении вы можете использовать модели из вашего контроллера, например:

Todo.findAll ({after: new Date ()}, myCallbackFunction);

Наконец, когда ваши задачи вернутся, вы должны их отобразить (# 4 ). Здесь вы используете представление JMVC.

'.show click' : function(el, ev){ 
   Todo.findAll({after: new Date()}, this.callback('list'));
},
list : function(todos){
   $('#todos').html( this.view(todos));
}

В «views / todos / list.ejs»

<% for(var i =0; i < this.length; i++){ %>
   <label><%= this[i].description %></label>
<%}%>

JMVC предоставляет гораздо больше, чем просто архитектуру. Это поможет вам в любой части цикла разработки с помощью:

• генераторов кода
• встроенного браузера, Selenium, и Rhino Testing
• Документация
• Сжатие скриптов
• Отчет об ошибках