Включайте файл JavaScript в частичные представления
Взаимодействие с пользователем в UIImageView по умолчанию отключено . Вы должны включить его явно, чтобы он реагировал на прикосновения.
imageView.userInteractionEnabled = YES;
6 ответов
Похоже, очень похоже на этот вопрос: Связывание библиотек JavaScript в пользовательских элементах управления
Я повторно отправлю свой ответ на этот вопрос здесь.
Я определенно не советовал бы их ставить внутри партиалов именно по той причине, которую вы упомянули. Существует высокая вероятность того, что одно представление может получить два частичных файла, которые имеют ссылки на один и тот же файл js. У вас также есть снижение производительности при загрузке js перед загрузкой остальной части html.
Я не знаю лучших практик, но я предпочитаю включать любые распространенные файлы js в главную страницу, а затем определять отдельный ContentPlaceHolder для некоторых дополнительные js-файлы, которые относятся к определенному или небольшому количеству представлений.
Вот пример главной страницы - он довольно понятен.
<%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>
<head runat="server">
... BLAH ...
<asp:ContentPlaceHolder ID="AdditionalHead" runat="server" />
... BLAH ...
<%= Html.CSSBlock("/styles/site.css") %>
<%= Html.CSSBlock("/styles/ie6.css", 6) %>
<%= Html.CSSBlock("/styles/ie7.css", 7) %>
<asp:ContentPlaceHolder ID="AdditionalCSS" runat="server" />
</head>
<body>
... BLAH ...
<%= Html.JSBlock("/scripts/jquery-1.3.2.js", "/scripts/jquery-1.3.2.min.js") %>
<%= Html.JSBlock("/scripts/global.js", "/scripts/global.min.js") %>
<asp:ContentPlaceHolder ID="AdditionalJS" runat="server" />
</body>
Html.CSSBlock & Html. JSBlock, очевидно, являются моими собственными расширениями, но опять же, они не требуют пояснений в том, что они делают.
Тогда, скажем, в представлении SignUp.aspx у меня будет
<asp:Content ID="signUpContent" ContentPlaceHolderID="AdditionalJS" runat="server">
<%= Html.JSBlock("/scripts/pages/account.signup.js", "/scripts/pages/account.signup.min.js") %>
</asp:Content>
HTHs, Charles
Ps. Вот следующий вопрос, который я задал об уменьшении и объединении файлов js: Объединить и минимизировать JS на лету ИЛИ во время сборки - ASP.NET MVC
РЕДАКТИРОВАТЬ: В соответствии с моим другим ответом, моя реализация .JSBlock (a, b) по запросу
public static MvcHtmlString JSBlock(this HtmlHelper html, string fileName)
{
return html.JSBlock(fileName, string.Empty);
}
public static MvcHtmlString JSBlock(this HtmlHelper html, string fileName, string releaseFileName)
{
if (string.IsNullOrEmpty(fileName))
throw new ArgumentNullException("fileName");
string jsTag = string.Format("<script type=\"text/javascript\" src=\"{0}\"></script>",
html.MEDebugReleaseString(fileName, releaseFileName));
return MvcHtmlString.Create(jsTag);
}
И тогда где происходит волшебство ...
public static MvcHtmlString MEDebugReleaseString(this HtmlHelper html, string debugString, string releaseString)
{
string toReturn = debugString;
#if DEBUG
#else
if (!string.IsNullOrEmpty(releaseString))
toReturn = releaseString;
#endif
return MvcHtmlString.Create(toReturn);
}
Я предпочитаю создать страницу plugin.master, унаследованную от вашего основного Site.master. Идея состоит в том, что вы помещаете эти плагины в plugin.master и делаете около 8 страниц, которые будут использовать это частичное представление для наследования от plugin.master.
Предпочтительный подход - помещать скрипты внизу , однако, если вы не можете этого избежать, то разумно поместить их посередине.
Браузеры обычно загружают различные элементы страницы параллельно, однако, пока браузер загружает файл Javascript, он не будет загружать другие элементы страницы параллельно, пока загрузка Javascript не будет завершена. Это означает, что ваши изображения и все остальное должны будут подождать, поэтому обычно считается, что лучше перемещать скрипты внизу, но если ваш скрипт небольшой, я бы не стал об этом беспокоиться.
Это похоже на похожий (хотя и не полностью) вопрос. Является ли плохой практикой возвращать частичные представления, содержащие javascript?
Разработчики MVC столкнулись с множеством проблем, чтобы помешать нам использовать код программной части, но, создав файл с именем
Я бы сказал, что лучшее место для включения было бы в обработчике Page_Load в фоновом коде (с использованием Page.ClientScript.RegisterClientScriptInclude).
Причина, по которой вы помещаете сценарий в нижней части страницы, заключается в том, чтобы убедиться, что домен был загружен, прежде чем пытаться выполнить какие-либо манипуляции. Этого также можно добиться с помощью метода $(document).ready(callback); jQuery.
Я разделяю мнение о том, что не следует помещать встроенный JavaScript в html. Вместо этого я использую Html helper для создания пустого div, чтобы использовать его в качестве инструкции для сервера. Помощник sig - Html.ServerData(String name, Object data);
Я использую этот метод ServerData для инструкций от сервера к клиенту. Тег div сохраняет чистоту, а атрибут "data-" является допустимым html5.
Для инструкции loadScript я могу сделать что-то вроде этого в моем ascx или aspx:
<%= Html.ServerData("loadScript", new { url: "pathTo.js" }) %>
Или добавить другой помощник для этого, который выглядит немного чище:
<%= Html.LoadScript("~/path/to.js") %>
Выход html будет:
<div name="loadScript" data-server="encoded json string">
Затем у меня есть метод jQuery, который может найти любой тег данных сервера: $(containingElement).serverData("loadScript"); // возвращает jQuery-подобный массив декодированных json-объектов.
Клиент может выглядеть примерно так:
var script = $(containingelement").serverData("loadScript");
$.getScript(script.url, function () {
// script has been loaded - can do stuff with it now
});
Эта техника отлично подходит для пользовательских элементов управления или скриптов, которые должны быть загружены внутри загруженного ajax-контента. Версия, которую я написал, немного более сложна в обработке кэширования скриптов, чтобы они загружались только один раз при полной загрузке страницы, и содержит обратные вызовы и триггеры jQuery, чтобы вы могли подключиться к ним, когда они будут готовы.
Если кого-то заинтересует полная версия этого (от MVC до расширения jQuery), я буду рад продемонстрировать эту технику более подробно. В противном случае - надеюсь, что это даст кому-то новый способ подхода к этой непростой проблеме.