Шаблоны пользовательского интерфейса в JavaScript

какие шаблоны пользовательского интерфейса вы обычно используете в JavaScript?

под шаблонами пользовательского интерфейса я имею в виду лучшие практики для создания и организации пользовательского интерфейса, генерируемого/управляемого из JavaScript (кроме библиотек, таких как jQuery или YUI).

например, если вы пришли из .NET world, вы знакомы с семейством шаблонов MVC (Model-View-Controller). В мире WinForms и ASP.NET вы встретите Model-View-Presenter. В WPF скорее всего вы найдете MVVM (Model-View-ViewModel) подход.

а как насчет JavaScript?

6 ответов


модели обычно зависит от языка. Если шаблон имеет значение, за исключением некоторых крайних случаев он будет иметь значение независимо от того, какой язык или технологию вы используете. Взять в MVC. Концепция отделения модели от представления от контроллера имеет значение независимо от того, реализована ли модель с помощью СУБД или какой-либо другой технологии, является ли представление HTML или Swing или X.

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

JavaScript сам по себе не навязывает вам какой-либо определенный шаблон. Некоторые фреймворки JavaScript, такие как YUI или Dojo или Glow, будут вести вас в одном направлении больше, чем в другом.

в конце концов, посмотрите на проблему, которую вы решаете, ресурсы и опыт, которые у вас есть, и следуйте шаблонам, которые имеют смысл.


Я хотел бы порекомендовать книгу Росса Хармса и Дастина Диаса, Pro JavaScript Шаблоны Проектирования, определенно лучший ресурс по этой теме, и определенно стоит прочитать.

есть также очень интересная статья о JavaScript MVC в последнем выпуске Список Только.


хороший подход к созданию GUI-приложения-это браузер:

  1. использование разметки для макета пользовательского интерфейса
  2. использование javascript UI logic
  3. использование CSS для UI styling

большинство современных фреймворков GUI (ExtJS, Dojo и т. д.) предлагают API, которые значительно помогают создавать GUI исключительно в JavaScript. Но есть еще один GUI framework достаточно SDK это приводит к вышеупомянутому разделению проблем. Это позволяет использовать XML-языки (XHTML, XUL, SVG) для макета, CSS для стиля и DOM API для логики пользовательского интерфейса.

для оркестровки клиентского приложения GUI вы можете использовать либо MVC, либо немного более продвинутый шаблон PAC, как для первого-есть PureMVC реализации

взгляните на следующий фрагмент (касается только логики пользовательского интерфейса, а не логики приложения, которая должна быть построена с MVC/PAC):

.HTML-код

<script type="application/ample+xml">
    <xul:tabbox onselect="fOnSelect(event)"
     xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
        <xul:tabs>
            <xul:tab label="checkbox" />
            <xul:tab label="textbox" />
            <xul:tab label="datepicker" />
        </xul:tabs>
        <xul:tabpanels>
            <xul:tabpanel>
                <xul:checkbox />
            </xul:tabpanel>
            <xul:tabpanel>
                <xul:textbox />
            </xul:tabpanel>
            <xul:tabpanel>
                <xul:datepicker />
            </xul:tabpanel>
        </xul:tabpanels>
    </xul:tabbox>
</script>

.в CSS

@namespace xul url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
xul|tab:focus {
    color: red;
}

.js

function fOnSelect(oEvent) {
    alert(oEvent.currentTarget.selectedItems.length)
}

как я знаю, пока нет конкретных шаблонов для Javascript. Но я думаю, что есть потенциал для чего-то вроде виджетов(компонентного) подхода. Поскольку в основном мы используем javascript для расширения возможностей нашего html-кода. Логично, что мы должны подключить каждый объект javascript к тегу html. Итак, здесь мы имеем что-то вроде Model(jsObject)+View(HTMLrepresentation). Чтобы получить MVC, нам нужны контроллеры, и у нас есть события для этого. В этом случае мы инкапсулируем легко extensibel деталь.

например:

// this is a part of some FormValid.js
<script>
function FormValid(){

}

FormValid.prototype.validate=function(){...}
</script>

//this is our HTML
<form id="form1"...onsubmit="this.jsObject.validate();">
</form>

<script>
//all the following stuff could be solved in one line, but you need to create some helper. Like Components.Attach("FormValid").to("form1");
var newObj=new FormValid()
var form=document.getElementById("form1");
from.jsObject=newObj;
newObj.htmlObj=form;
</script>

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

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

// this is a part of some FormValid.js
<script>
function FormValid(){

}
Components.extendCore(FormValid);

FormValid.prototype.validate=function(){...}
</script>

FormValid.prototype.templates={
   main:'<form class="form1"...onsubmit="this.jsObject.validate();">...</form>'
}

//this is our HTML
<div id="form1"></div>
<script>
Components.Attach("FormValid").to("form1");
</script>

Я все еще думаю, что последний inline <script> должно быть там, и это не смешивание логики с представлением, потому что это компонент - сплошная часть. Одно без другого не имеет смысла. На самом деле это должно быть частью приложения. Что-то вроде html компонента (в las одним из примеров является div) должно быть определено и обернуто компонентом, который автоматически добавлять скрипты и коды.

сейчас. Я показал вам 2 примера, и я объясню, почему второй слишком специфичен.
все вещи в доступности и производительности(и утечки памяти). Если вы будете часто обновлять весь html компонента-он будет мигать, также вам нужно будет настроить все динамические события и проверить все на наличие утечек памяти. Но главная проблема, если JS потерпит неудачу - ваше приложение ничего не покажет.

поэтому я предпочитаю иметь выбор между эти два:) и использовать все на своих местах.


проверьте сайт под названием айва. Я не уверен, сколько шаблонов здесь являются шаблонами пользовательского интерфейса javascript. Но это довольно хороший ресурс для шаблонов ui


Шаблоны не всегда зависят от языка. Многие классические шаблоны дизайна бессмысленны в JavaScript, потому что нам не нужно много обходных путей, которые они решают в более строгих парадигмах langauge.

причина, по которой MVC не так подходит для веб-разработки на стороне клиента, однако более ситуативна.

прежде всего, я думаю, что время и боль доказали, что типичные веб-приложения лучше всего рассматривать как два отдельных приложения. Что происходит в браузере и то, что происходит на сервере. Чем меньше зависимостей вы устанавливаете между ними, тем более гибкие, поддерживаемые и простые веб-приложения были изменены в моем опыте. М бизнес-логики (люди стремятся incaccurately объединить с "базой данных" ИМО).

проблема с MVC в этом сценарии заключается в том, что мы не хотим выставлять бизнес-логику на стороне клиента и пытаться объединить все приложение в одну отвратительную конструкцию http-divide-hiding болезненно, как я уже упоминал.

очень похожие шаблоны, где вы отделяете данные или проблемы "view model", могут работать довольно хорошо.