我们正处于将Script#引入我们的项目的早期阶段,到目前为止我们喜欢我们所看到的。但是,我对将脚本添加到单个页面/视图的最佳策略感到困惑。
简而言之,我们的asp.net mvc项目有很多控制器和许多视图。这些视图中的每一个都为我们的部分应用程序提供了不同的功能。
似乎脚本#确实能够为不同的文件夹输出许多不同的脚本,如果你这样设置它,但我在StackOverflow的其他地方看到了一个回应,暗示这种方法是不受欢迎的。
我可以看到每页脚本编写的另一种方法是在$(Document).Ready()
中调用每个视图的方法调用,调用脚本中与视图名称匹配的方法或类似的东西。这可行,但我不太喜欢这个想法。
其他人如何处理这个问题?
答案 0 :(得分:1)
我认为有两种动机(通常基于之前关于该主题的对话)
为了解决#1问题,曾经有一个解决方案,其中单个c#项目可以按比特编译以生成多个脚本,但这已经消失了。之所以消失,是因为c#编译器一次编译一个完整的项目,并且脚本#一次编译项目的一部分,因此很容易拥有不同的语义。然而,一切都没有丢失 - 你有几个选择。
自定义msbuild进程 - 专门更改csproj以使用代码子集多次调用ScriptCompilerTask。您负责确保每个代码子集都成功编译,因为c#编译器提供的验证意义不大。
使用Script#compiler API编写自定义msbuild任务。您可以在github [1]中的脚本#vorage中看到msbuild任务的实现,并将其基于...您甚至可以回顾源代码的历史记录,以了解msbuild任务如何用于提供此功能。 / p>
要解决#2问题,最好根据您的应用场景考虑哪些有意义的脚本集并以这种方式加载它们而不是每页严格的一个特定脚本文件(一旦您考虑缓存,http请求等。)。
因此,假设您将多个页面的脚本合并为一个脚本。现在解决在页面上加载恰当脚本的问题。这就是我所做的:
在我的页面中,我注释了body标签:
<body id="editPage">
在我的脚本#中,我有以下内容:
internal static class EditPage {
static EditPage() {
jQuery.OnDocumentReady(delegate() {
if (Document.BodyElement.ID == "editPage") {
// Code you want to run on editPage
}
});
}
}
有多种方法可以实现这一点,但您不必在每个页面中严格编写一些代码来调用正确的API。希望这给出了一些替代方案,它们在脚本中包含了所有逻辑。
脚本#中的一个示例(请参阅https://github.com/nikhilk/scriptsharp/blob/cc/samples/AroundMe/AroundMe/Page.cs#L38)执行类似于有条件运行的代码。
这样做的一个很好的副作用是大多数代码都可以转换为内部类,因为视图从不直接调用脚本。而是脚本以不引人注目的方式向页面添加行为。当然,好处是可以极大地提高脚本的可最小化性。