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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

например:

// 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 node, поэтому обновляется VIEW нашего объекта. Это в основном идея, и наш код становится:

// 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>

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

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

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

Ответ 4

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

• с использованием разметки для макета пользовательского интерфейса
• с использованием логики пользовательского интерфейса javascript
• Использование CSS для стилей UI

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

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

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

index.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>

index.css

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

index.js

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

Ответ 5

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

Ответ 6

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

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

Прежде всего, я думаю, что время и боль доказали, что типичные веб-приложения лучше всего рассматривать как два отдельных приложения. Тот, который происходит в браузере и тот, который происходит на сервере. Чем меньше зависимостей вы устанавливаете между этими двумя, тем более гибкими, удобными и удобными веб-приложениями были модифицированы в моем опыте. M - это бизнес-логика (в которой люди склонны неточно сливаться с "уровнем базы данных" IMO).

Проблема с MVC в этом сценарии заключается в том, что мы не хотим раскрывать бизнес-логику на стороне клиента и пытаться превратить все приложение в одну отвратительную конструкцию, скрывающую скрытый http-divide, как было сказано выше. /p >

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