脚本组织模式(MVC + jQGrid)

发布于 2024-10-18 15:01:51 字数 1033 浏览 5 评论 0原文

我正在构建一个 MVC Web 应用程序,大量使用 ajax 加载的包含 jQGrids 和 javascript 的部分视图。许多部分视图仅包含 2 个 div 标签,其余部分是 javascript。

对我来说,使用脚本标签使一般页面结构更具逻辑性,因为 JavaScript 就是我所看到的页面内容。

然而,还有 jQGrid 使用的小型实用函数,例如格式化函数,并且我开始发现同名脚本执行几乎相同任务的风险越来越大。

格式化函数的示例:

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

            default:
                break;
        }

        return "";
    };

起初,我看到格式化函数属于最近的网格,特别是因为可能有其他网格具有相同名称的格式化函数,但代码中存在一些细微的差异。

我同时加载两个或多个网格,如果存在名称冲突,JavaScript 似乎足够聪明,可以使用当前脚本块中定义的脚本,因此除了烦人的想法之外,没有任何问题,“这是最好的方法吗?”做这个?”。

还有用于从网格操作中加载 ajax 和显示 jQuery 对话框的脚本。我认为脚本会随着时间的推移而增加。

我应该将脚本保留在使用它们的地方还是应该尝试构建某种类型的脚本库?

如果我应该将它们移到脚本文件中,那么对函数(名称)进行分区的明智方法是什么? 、类、文件...)? 如果我将它们移出,它们是否会被认为更不引人注目,因为这种类型的页面已经由 ajax 本身加载并包含 95% 的 JavaScript?

我意识到存在类似问题,但我没有找到任何合适的答案。如果有问题,我会删除它。

I'm building a MVC web app with heavy use of ajax loaded partial views containing jQGrids and javascripts. Many of the partial views contains only 2 div tags and the rest is javascripts.

Using script tags makes the general page structure much more logic to me, because the javascripts are the content of the page as I see it.

However there are also small utilityfunctions, like formatting functions, used by jQGrid and I'm starting to see an increasing risk of scripts with the same name performing almost identical tasks.

Example of formatting function:

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

            default:
                break;
        }

        return "";
    };

At first I saw the formatting functions as belonging to the closest grid, especially since there might be other grids having a formatting function with the same name but with some small differences in the code.

I load two or more grids at the same time, it seems that javascript is smart enough to use the script defined in the current script block if there's a name clash so there's no problem yet beyond the nagging thoughs, "is this the best way of doing this?".

There's also scripts for ajax-loading and displaying jQuery dialogs from grid actions. I'm thinking that the scripts will add up over time.

Should I just keep the scripts where they are used or should I try to build a script library of some kind?

If I should move them out to script files, what's a smart way of partitioning the functions (names, classes, files...)?
If I move them out, would they be considered more unobtrusive as this type of page is already loaded by ajax itself and consisting to 95% of javascripts?

I realize there are similar questions but I didn't find any suiting answer. If there's a problem with this, I'll delete it.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

妄想挽回 2024-10-25 15:01:51

对象文字

避免不必要的全局命名空间污染的最简单方法是将相关函数放在对象文字:

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();

无论哪种情况,您最终都会在全局命名空间中得到一个变量,这是一个胜利。

Object Literals

The simplest way to avoid unnecessary pollution of the global namespace is to place related functions in an object literal:

var Formatter = {

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

    someOtherFormatter: function() {

    }
}

Which can then be used like this:

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

This results in one property on the global object instead of one for each function you define.

Module Pattern

Or you could hide things with function scope:

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

Which can be used like this:

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

In either case, you end up with just one variable in the global namespace, which is a win.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文