Такие базы данных кода операции уже реализованы в различных компиляторах, которые компилируются в нативный код.
Например, LLVM имеет такие базы данных в форме языковых файлов TableGen. Внутренние дизассемблеры в основном создаются автоматически из этих описаний. Взгляните, например, на Sparc backend .
Такие проекты, как Capstone Disassembler , используют LLVM для дизассемблирования кода для различных процессоров.
Поскольку вы не отправляете обратно, чтобы изменить стиль div, когда пользователь нажимает кнопку «Назад», он возвращает его к исходной публикации страницы. Самый простой способ исправить это - заставить кнопку вызывать обратную передачу, которая переключает стиль.
Большинство изменений в DOM не сохраняется, когда Вы возвращаетесь к странице с помощью Кнопки "Назад" в Chrome. (Я полагаю, что это может отличаться в других браузерах, поскольку они реализуют BFcache (назад вперед кэш), который в настоящее время в разработке для Chrome.)
то, Что , сохранилось однако, входные значения, как переключатели и скрытые исходные данные.
Так, при хранении изменений в (скрытых) исходных данных Вы могли бы восстановить свой DOM на pageshow событие . (Поддержка события кажется так себе, если Вы проверяете, что страница Mozilla, но CanIUse.com более оптимистичен: https://www.caniuse.com/#search=pageshow)
Сохраните настройку в файле cookie на стороне клиента, затем проверьте файл cookie с помощью JavaScript при загрузке страницы и измените класс CSS. Другие способы исправить это могут не работать, потому что страница не всегда запрашивается с сервера, когда пользователь нажимает кнопку Назад
.
с использованием плагина jQuery cookie
// this function will update the style of the divs based on the cookie's settings
function updateClass(){
var val = $.cookie('myCookieName');
// set your div's class
if (!val || val=='divA')
{
$('#divA').removeClass('SearchDivDisabled');
$('#divA').addClass('SearchDiv');
$('#divB').removeClass('SearchDiv');
$('#divB').addClass('SearchDivDisabled');
}else{
$('#divB').removeClass('SearchDivDisabled');
$('#divB').addClass('SearchDiv');
$('#divA').removeClass('SearchDiv');
$('#divA').addClass('SearchDivDisabled');
}
}
// call this passing in 'divA' or 'divB' depending on which is selected
function updatePage(selectedDiv){
$.cookie('myCookieName', selectedDiv, { path: '/', expires: 10 });
updateClass();
}
// change the class of the divs when the page is finished rendering
$(document).ready(function(){updateClass();}):
Я не думаю, что проблема в ViewState; это может быть что-то, что необходимо управлять в коде javascript на стороне клиента, поскольку переключение состояний на клиенте не отражается автоматически на сервере ...
То, что вы хотите потенциально рассмотреть, это управление историей браузера через функция точек истории: http://msdn.microsoft.com / en-us / library / cc488548.aspx
HTH.
Как упоминалось в моем предыдущем ответе, вы можете получить все, что вам нужно, с помощью переменных сеанса. Поскольку вы упомянули о сохранении выбора DIV, я попросил вас указать это в переменной сеанса. Если вы хотите, чтобы другие данные формы сохранялись, выгрузите их все в переменных сеанса (убедитесь, что вы очистили их, когда закончите с ними)
Это будет самый простой способ удовлетворить ваши требования.
Также вы используете
Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
Response.AppendHeader("Expires", "0"); // Proxies.
, вы можете просто использовать
Response.Cache.SetCacheability(HttpCacheability.Private);
в своей Page_load и получить ту же функциональность
Сообщите мне, если у вас есть какие-либо особые проблемы с реализацией этого.
Вы можете сохранить идентификатор div, для которого в настоящее время установлен класс SearchDiv, в переменной SESSION, прежде чем выполнять перенаправление в кнопке поиска, во время загрузки страницы поиска получите div и установите для него соответствующий класс.
Таким образом, вы можете продолжать использовать свой javascript для переключения классов в div и сохранять данные только перед перенаправлением на другую страницу и избегать ненужной публикации
Это можно решить одним из двух способов.
Если каждая форма поиска отправляет сообщения на другой URL-адрес, то каждый URL-адрес должен установить переменную сеанса, называемую, например, «LastSearchMethd», в значение «A» или «B». Если они оба публикуют один и тот же URL-адрес, просто включите скрытое поле, содержащее «A» или «B» для каждой формы соответственно, и сохраните отправленное значение в переменной сеанса.
В любом случае вам нужно отобразить стиль каждого DIV в зависимости от значения переменной сеанса.
Как упоминалось в других постах, правильное кэширование также будет рассматриваться.