Шаблоны организации сценариев (MVC + jQGrid) - PullRequest
Новая
       41

Шаблоны организации сценариев (MVC + jQGrid)

1 голос
/ 24 февраля 2011

Я создаю веб-приложение MVC с интенсивным использованием загруженных ajax частичных представлений, содержащих jQGrids и javascripts. Многие частичные представления содержат только 2 тега div, а остальные - javascripts.

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

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

Пример функции форматирования: 

    function primaryRoleFormatter(cellvalue, options, rowObject) {
        switch (cellvalue) {
            case "1":
                return "<%= Resource.PRIMARY %>";

            default:
                break;
        }

        return "";
    };

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

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

Есть также скрипты для ajax-загрузки и отображения диалогов jQuery из действий сетки. Я думаю, что со временем сценарии будут складываться.

Должен ли я просто хранить сценарии там, где они используются, или я должен попытаться создать какую-нибудь библиотеку сценариев?

Если мне нужно переместить их в файлы сценариев, каков разумный способ разделения функций (имен, классов, файлов ...)? Если я уберу их, будут ли они считаться более ненавязчивыми, поскольку страница такого типа уже загружена самим ajax и состоит из 95% javascripts?

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

1 Ответ

4 голосов
/ 24 февраля 2011

Литералы объектов

Самый простой способ избежать ненужного загрязнения глобального пространства имен - это поместить связанные функции в литерал объекта: 

var Formatter = {

    primaryRoleFormatter: function(cellvalue, options, rowObject) {
        switch (cellvalue) {
            case "1":
                return "<%= Resource.PRIMARY %>";
            default:
                break;
        }
        return "";
    },

    someOtherFormatter: function() {

    }
}

.использоваться следующим образом: 

Formatter.primaryRoleFormatter(cellvalue, options, rowObject);
Formatter.someOtherFormatter();

Это приводит к одному свойству глобального объекта вместо одного для каждой определяемой вами функции.

Шаблон модуля

Или вы можете скрыть вещи с помощью области действия функции: 

var Formatter = (function() {

    function FormatterCtor() {
        // instance-ish level func
        this.onePerInstance = function() {}
    }

    // not accessible from the outside; not in the global namespace
    function privateFunction() {}

    // class-ish level func
    FormatterCtor.oneShared = function() {}

    return FormatterCtor;

})(); // self-executing

Что можно использовать следующим образом: 

var fmt = new Formatter();
fmt.onePerInstance();

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

...