Шаблоны пользовательского интерфейса в 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-приложения-это браузер:
- использование разметки для макета пользовательского интерфейса
- использование javascript UI logic
- использование 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", могут работать довольно хорошо.