Исключение нулевого указателя - это индикатор того, что вы используете объект, не инициализируя его.
Например, ниже - класс ученика, который будет использовать его в нашем коде.
public class Student {
private int id;
public int getId() {
return this.id;
}
public setId(int newId) {
this.id = newId;
}
}
Приведенный ниже код дает вам исключение с нулевым указателем.
public class School {
Student obj_Student;
public School() {
try {
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
Поскольку вы используете Obj_Student
, но вы забыли инициализировать его, как в правильном коде, показанном ниже:
public class School {
Student obj_Student;
public School() {
try {
obj_Student = new Student();
obj_Student.setId(12);
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
http://ejohn.org/blog/javascript-micro-templating/ - чертовски блестящий взлом для этого. Конечный результат очень чистый.
У нас была система, в которой много данных передавалось в виде JSON с сервера, а затем обрабатывалось через механизм шаблонов JavaScript на стороне клиента. В .Net 4.0 (может быть, даже 3.5 sp1, я не уверен), это можно сделать с помощью клиентских шаблонов .
Я бы предпочел передавать JSON, а не отправлять html. Всегда хорошо хранить данные и просматривать отдельно.
Я тоже предпочитаю ответ JSON с логикой создания HTML на стороне клиента.
К сожалению, большинство реальных сценариев написания HTML-кода на стороне клиента повреждены и содержат множество недостатков HTML-инъекций, которые легко могут стать дырами в безопасности межсайтовых сценариев. Я думаю, что убеждение состоит в том, что, поскольку вы общаетесь с собственным сервером, а не напрямую с враждебным пользователем, вы в некотором роде «в безопасности» и можете без правильных строк уйти, вставляя их в HTML. Что, конечно, ерунда.
Я всегда вижу такие вещи, как:
$('#mydiv').append('<em>Deleted '+response.title+'!</em>');
или:
mydiv.innerHTML= '<p>Renamed to '+response.name+'</p>;
или действительно микротемплинг взлома Ресига, где по умолчанию не выполняется экранирование HTML. Приходите на , люди! Мы только начали очищать устаревшие скрипты PHP, обслуживающие XSS на стороне сервера, теперь вы хотите представить целый новый огромный спектр XSS-эксплойтов на стороне клиента?
Вздох. Это Приманка Струн. Мы думаем, что понимаем их и можем объединить их вместе. Но строки предательские, со скрытым контекстом и уклонением от требований. Если вам нужно сгенерировать HTML на стороне клиента, вам понадобится такая функция:
function h(s) {
return s.split('&').join('&').split('<').join('<').split('"').join('"');
}
mydiv.innerHTML= '<p>Renamed to '+h(response.name)+'</p>;
Но лично я предпочитаю методы DOM. Как и при параметризации для SQL, использование методов DOM устраняет расслоение строк в уравнении, передавая необработанные строки непосредственно компонентам, которые будут их использовать. Хорошо, проблема с DOM заключается в том, что он довольно многословный:
var p= document.createElement('p');
p.appendChild(document.createTextNode('Renamed to '+response.name))
mydiv.appendChild(p);
Но вы всегда можете определить вспомогательные функции, чтобы сократить это, например :[
mydiv.appendChild(makeElement('p', {}, 'Renamed to'+response.name));
(Новый Материал для создания элементов в jQuery 1.4 использует похожий стиль.)
+1 год назад, мы начали новое веб-приложение и нуждались в способе рендеринга HTML из данных JSON, в браузере.
Мы хотели так быстро, как преобразование XML / XSLT.
Наш ответ на это был шаблон JS-двигателя .
В отличие от большинства шаблонов JS-шаблонов, оно держит HTML нетронутым (вообще никаких странных меток) и за исключением нескольких обозначений, он не приносит новый язык для изучения, только JS и HTML.
То, как я его использую:
Если вы хотите сохранить Framework MVC, вы должны позволить вашему шаблону Framework сделать шаблон. AJAX должен выполнять только запрос сервера, который выполняет все дБ и бизнес-логику, а затем возвращает URL на шаблон, который должен быть загружен.