Я бы посоветовал вам отправить значение true
или false
через контроллер
public String activate(Map<String, String> model, @PathVariable String code) {
boolean isActivated = userService.activateUser(code);
// TODO: change to boolean in template
if (isActivated) {
model.put("message", "User Successfully activated");
} else model.put("message", "Activation code not found");
model.put("isActivated", isActivated);
return "verificationPage";
}
. В html вы можете попробовать
<div th:if="${isActivated} == true"><p>User Successfully activated .</p></div>
<div th:unless="${isActivated}"><p>Activation code not found.</p></div>
Обновлено ] `
В вашем случае вы можете просто напечатать сообщение в одиночку, вам вообще не нужно иметь условие if
.
<div ><p>${message}</p></div>
Один запрос, который возвращает дюжину частей данных, почти 12x быстрее, чем 12 запросов, которые возвращают 1 часть данных.
О, и НИКОГДА НИКОГДА не помещаемый SQL в цикле, это будет всегда вводить аварию.
В зависимости от того, как работает Ваше приложение, новое соединение могло бы быть открыто для каждого запроса, это особенно плохо, поскольку каждый сервер БД имеет предел на количество соединений. Затем также поймите, что это произойдет для каждого пользователя, таким образом, 50 запросов с 5 пользователями и у Вас уже будет 250 запросов в любой данный момент. Но даже если все запросы действительно совместно используют всего 1 соединение, Вы облагаете налогом времена сервера БД X больше, замедляя его для всего остального, каждой страницы, потому что пользователи являются hogging сервер БД на этой странице, и все должны совместно использовать.
Я видел сбой целого приложения в прошлом из-за этого 1 недостатка дизайна, просто не делайте этого.
Я соглашаюсь с другими - и я - тот, который разработал и кодировал связи между таблицами API в Платформе Зенда, которую Вы используете!
findDependentRowset()
полезно, если у Вас уже есть ссылка на родительскую строку, и Вам, возможно, понадобилось бы к связанным с выборкой строкам. Эта функция не эффективна ни в малейшей степени, по сравнению с запросом, присоединяющимся к обеим таблицам. Вы не должны звонить findDependentRowset()
в цикле, когда-либо, если производительность является приоритетом вообще. Вместо этого запишите SQL-запрос, состоящий из СОЕДИНЕНИЯ обеих таблиц.
Неудачно ретроспективно, что целью Зенда для их Платформы была простота дизайна, а не производительности.
Если бы я продолжил работать в Пехлеви, то я попытался бы улучшить интерфейс Table с удобным способом выполнить запросы, к которым присоединяются, против связанных объектов Zend_Db_Table. Решение, реализованное после того, как я оставил проект, состоит в том, чтобы создать Избранный объект и передать его fetchAll()
, который ужасно ужасен.
править: В ответ на Ваш комментарий я приложил все усилия для создания решения, данного ряд требований. Я чувствую себя прекрасно о том, что я сделал. Но Пехлеви является компанией инструментов IDE, таким образом, естественно их значение находится в удобстве кодирования, не производительности во время выполнения. "Быстрая разработка приложений" может означать разрабатывать быстрые приложения или разрабатывать приложения быстро. Для компании инструментов это означает последнего.