Я должен добавить поддержку PropertyChangeSupport и PropertyChangeListener в бобе Java для веб-приложения?
Преобразование миллисекунд в формат даты с использованием javascript
- для справки см. Ниже jsfiddle
http://jsfiddle.net/kavithaReddy/cspn3pj0/1/
function () {
var values = "/Date(1409819809000)/";
var dt = new Date(parseInt(values.substring(6, values.length - 2)));
var dtString1 = (dt.getMonth() + 1) + "/" + dt.getDate() + "/" + dt.getFullYear();
alert(dtString1);
})();
3 ответа
Честно говоря, беспокойтесь только в том случае, если вам действительно понадобится эта функция . Большинству веб-приложений не требуется PropertyChangeSupport . На самом деле я не могу вспомнить, чтобы он использовался в каком-либо веб-приложении, которое я видел. Я видел только его использование в приложении Swing.
Типичный bean в веб-приложении - это довольно недолговечный объект, подготовленный для обслуживания единственного запроса, а затем отброшенный в пустоту для быть собранным мусором.
PropertyChangeListener в любом случае имеет довольно плохой дизайн - все это волшебное сравнение строк. Гораздо лучше использовать простые модели с ChangeListener (или аналогичные) и объединить их с составными моделями.
Если вы не делаете что-то интерактивное и COMETy, тогда это не имеет большого смысла в веб-приложение. Обычно у вас есть модель pull, в которой вся текущая информация объединяется за один раз. Это может иметь смысл там, где у вас есть кеши.
Вы даже можете писать настольные приложения таким же образом, как и веб-приложения. Любое изменение (или серия изменений) и синхронизируйте графический интерфейс. Это получается довольно компактно. Кроме того, затраты на производительность переносятся из критического времени серьезных изменений (таких как открытие окна) на некритическое время, когда у вас есть циклы, которые нужно сжечь.
1) Не добавляйте поддержку изменения свойств, если вы не знаете, что она вам понадобится.
2) Если ваш bean-компонент - это просто объект значения, не имеющий ничего, кроме геттеров / сеттеров / равных / hashcode, а затем рассмотрите возможность использования структуры АОП (мне нравится Spring), чтобы обернуть объект советами, используемыми для реализации событий / поддержки изменения свойств. Таким образом, ваш bean-компонент остается незагрязненным логикой, которая нужна только в определенных контекстах (обычно пользовательский интерфейс) и которая может изменяться в разных контекстах. Это урок, который я усвоил, когда добавил поддержку изменения свойств для всех компонентов домена для конкретного приложения - пользовательский интерфейс использовал это, но это сбило с толку команду сервера (там не использовалось) и было просто шумом там, где оно не использовалось.
Я также согласен с тем, что иногда вам не нужно слушать отдельные свойства,