Аналогичный подход к тому, предложенному @anjanb
builder.setEntityResolver(new EntityResolver() {
@Override
public InputSource resolveEntity(String publicId, String systemId)
throws SAXException, IOException {
if (systemId.contains("foo.dtd")) {
return new InputSource(new StringReader(""));
} else {
return null;
}
}
});
, я нашел, что просто возврат пустого InputSource работал точно также?
Viewstate, если вам не нужно ссылаться на него в клиентском скрипте. Скрытое поле, если вы это сделаете.
Также учтите, что если данные являются конфиденциальными, Viewstate по умолчанию зашифрован, тогда как скрытое поле по умолчанию сохраняет его как простой текст, видимый всем, кто знает, как просматривать исходный код.
Редактировать
Согласно примечанию @Andrew Hare к его собственному ответу, я редактирую это. Это достаточно важное различие, которое стоит отметить. Я бы не хотел, чтобы кто-то думал, что они "безопасны", используя Viewstate на основании моего надзора.
Viewstate НЕ зашифрован по умолчанию, он хранится в кодировке Base-64. Его можно довольно легко декодировать, поэтому использование Viewstate, поскольку оно зашифровано по умолчанию, недопустимо. Это лучше, чем обычный текст, но не для тех, кто умеет гуглить "
Это не имеет особого значения, поскольку ViewState хранится в скрытом вводе. Используйте тот, который вам удобнее. Если бы это было мое решение, я бы выбрал ViewState, поскольку среда выполнения ASP.NET будет обрабатывать сериализацию и десериализацию ваших объектов за вас.
Мне нравится ViewState - его намного сложнее взломать - неприятный человек может легко отправить вам вашу страницу с неверными данными в скрытых полях
Вы хотите сохранить его в Состояние просмотра. Скрытые поля могут быть обновлены в браузере, поскольку они предназначены для хранения информации, которой можно управлять на стороне клиента. Состояние просмотра будет проверяться asp.net на предмет несанкционированного доступа, при этом вам придется сделать это самостоятельно со скрытым полем.