Встроенный скрипт не разрешается в настраиваемом элементе управления ASP.Net
В настоящее время я работаю с валидатором регулярных выражений обычай(к несчастью).
Я пытаюсь установить шаблон Regex, используя встроенный скрипт на стороне сервера, например:
ValidationExpression = "<%= RegExStrings.SomePattern %>"
Однако сценарий не разрешается в код на стороне сервера. Вместо этого он интерпретируется буквально, и я получаю что-то вроде этого в визуализированной разметке:
ctl00_DefaultContent_regexValidatorInvitation.validationexpression = "<%= RegExStrings.SomePattern %>";
Есть какие-нибудь подсказки относительно того, почему это не разрешается должным образом?
Ответы 8
Значения в веб-элементе управления не отображают код на стороне сервера. Скорее установите это из кода позади
RegExValidator1.ValidationExpression = RegExStrings.SomePattern;
Это не имеет смысла, поскольку этот стиль встроенного скрипта постоянно используется для привязки данных в веб-элементах управления.
Если бы вы могли предоставить документацию, подтверждающую это, я был бы немного менее скептичен. Я знаю, что могу установить это в выделенном коде, но в этом нет необходимости.
Он воспринимается как буквальная строка, попробуйте
ValidationExpression = '<% = RegExStrings.SomePattern%>'
Обновлено: приведенное выше не работает, я попытался понять, как это сделать безуспешно, я обычно устанавливаю свойства в коде программной части и использую этот синтаксис для привязки данных только тогда, когда мне нужно. Мне было бы интересно узнать, можно ли это сделать.
Проблема не в этом. Независимо от того, поставлю ли я одинарную или двойную кавычку, не имеет значения. ASP.Net использует все, что находится внутри операторов <%%>, как код на стороне сервера.
Если ваш валидатор регулярных выражений имеет атрибут runat = "server", измените его из кода, стоящего за ним. Было бы намного проще.
Но почему это? Я могу воспроизвести вашу проблему, используя простую страницу aspx, как показано ниже:
<%@ Page language = "c#" AutoEventWireup = "true" %>
<html>
<body >
<form id = "Form1" method = "post" runat = "server" action = "?<%=Request.QueryString%>">
Query String value: <%=Request.QueryString %>
<br />
<input type=submit />
</form>
</body>
</html>
После отправки формы отобразится следующее:
Query String value: %3c%25=Request.QueryString%25%3e
По какой-то причине встроенный код не выполняется, когда runat = "server" присутствует. Странно у меня 3 машины которые не ведут себя так, и тот, который так себя ведет, поэтому я могу только предположить что это проблема конфигурации IIS / .NET, возможно, вызванная недавним MS Обновлять. Программное обеспечение, которое я недавно установил на машине демонстрирует такое поведение: Visual Studio 2008 WSE 3.0 IE8 RC1
Интересно, вызвало ли это что-нибудь из этого?
Спасибо за ваше тщательное расследование этого вопроса :) Честно говоря, я отказался от этого, но вы, кажется, очень настроены. Кроме того, надеюсь, повышение репутации тоже вам немного поможет;)
вы пробовали ... <form id = "Form1" method = "post" runat = "server" action = "<% = String.Concat (" "?" ", Request.QueryString)%>">
Это сообщение появилось в поиске Google для решения проблемы, опубликованной в вопросе с идентификатором 18303866. ASP.Net (Visual Studio) не рассматривает «<% =%>» как встроенный код, а скорее как «% 3c% 25 =%. 20% 25% 3e "как во время разработки, так и во время выполнения. Один проект в решении работает, а другой - нет.
Вы используете выражение привязки данных для элемента управления, который не привязан к данным. Вам нужно вызвать DataBind () или использовать реализацию ExpressionBuilder. Простой ExpressionBuilder для привязки к произвольному коду можно найти по адресу http://weblogs.asp.net/infinitiesloop/archive/2006/08/09/The-CodeExpressionBuilder.aspx
devstuff, это не объясняет, почему это работает на трех моих машинах, но не на четвертой, не так ли? Все они используют одну и ту же версию .NET Framework и настройки IIS (я считаю, проверив столько, сколько я coukd)
Я удалил .NET framework, исследуя это (3.5, затем 3.0 и 2.0) - у меня не было проблем после Установка каждого из следующих: .net framework 2.0 .net framework 2.0 с пакетом обновления 1 (SP1) .net framework 3.0 .net framework 3.0 с пакетом обновления 1 (SP1) .net framework 3.5
Но после того, как я установил .net framework 3.5 SP1, поведение вернулось - я думаю, это проблема. Я поднял этот вопрос в Microsoft и обновлю эту ветку, когда получу ответ.
Теперь это прояснилось в моем РС. Обнаруженная мной проблема была вызвана тем фактом, что атрибут «действие» в серверных формах не действовал до .NET 2 SP2, но теперь его можно установить. Блоки рендеринга кода никогда не работали со значениями атрибутов - это объясняется в конце этого поста.
Это было следствием преднамеренного изменения поведения, введенного в Microsoft .NET Framework 3.5 SP1. До пакета обновления атрибуты действий и методов в тегах FORM на стороне сервера нельзя было переопределить. Если указано, они будут заменены ASP.NET с «POST» и «именем страницы».
Ранее синтаксический анализатор страницы ASP.NET не препятствовал указанию этих атрибутов, хотя документация не рекомендовала это для атрибута действия: http://msdn.microsoft.com/en-us/library/k33801s3.aspx
В частности, комментарий (в контексте элемента FORM):
• «Открывающий тег не должен содержать атрибут действия. ASP.NET устанавливает эти атрибуты динамически при обработке страницы, переопределяя любые настройки, которые вы могли сделать».
Проблема, о которой первоначально сообщил Джош, когда блок кода не интерпретировался, не является новым поведением, а является известной ошибкой - блоки визуализации кода не могут использоваться в атрибутах управления сервером. Об этом сообщается как об ошибке «Подключиться»: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=109257 который содержит следующее: «Атрибуты серверных элементов управления не могут принимать встроенное выражение в качестве значения. Это объясняет непредвиденное поведение, которое наблюдается с:« <link href = "<% = RootPath%> ...» Однако встроенный код может использоваться для значений атрибутов. "
Потрясающее расследование по этому поводу! Я очень ценю вашу работу по этому вопросу.
Не могли бы вы опубликовать больше кода, например, весь контрольный тег? Отсюда я вижу, что это скорее проблема ASP.net, чем проблема с элементом управления.