______
* Надпись на португальском языке переводится так: «Нет больше такого места, как наш домашний очаг». Lar — «домашний очаг» по-португальски.

WordPress вообще очень хорошая блогообразная CMS; плюсом является то, что систему можно использовать не только как блог, но и как сайты другого типа. Например, форум прикрутить или назначить главной страницей статическую. В общем, при желании можно сделать из него конфетку.
Несомненно, 2-3 мегабайта исходников (это только в архиве) — явный перебор. Скорость работы из-за этого сильно снижается.
Есть несколько вещей, которые кем-то могут считаться плюсами, а кем-то минусами.

1. Система шаблонов. Почему в ней совмещены и HTML, и PHP-код — неясно. Можно было бы оставить на откуп шаблонам только разметку с системными тэгами, которые динамически заменялись бы на программную логику. Но в этом случае всю систему придётся переписать. С другой стороны, такой подход позволяет не только перекроить шаблон, но и добавлять собственный функционал.
2. Работа с комментариями сделана, мягко говоря, непродуманно. Капчи (защиты) изначально нет: здравствуй, спам. Настроить вывод комментов для удаления нельзя. Отключить комментирование разом нельзя. На один из наших сайтов была спам-атака, за день 18 тысяч новых комментов, которые по 20 штук удалять было никак не оптимистично. Доступа к базе напрямую тоже нет, чтобы удалить все неодобренные комменты одним запросом: DELETE from wp_comments WHERE comment_approved = '0';. Страница модерирования от такого количества тоже умерла. Переименовал скрипт добавления комментов (а вот у меня во фреймворке одну галочку для этого надо поставить в настройках, чтобы запретить комментирование), изменил скрипт администрирования комментов на PHP, чтобы по 400 комментов разом можно было сносить (если больше, то система вешается и не отдаёт страницу в админке), поудалял комменты, нашёл плагин с капчей, активировал, обратно переименовал скрипт добавления…
3. Плагины. Страшное дело. Это путь фаерфокса: без плагинов только основаная функциональность, очень-очень основная, зато с плагинами рай земной. Только чем больше плагинов, тем больше система тормозит. А функциональность-то нужна: нормальные адреса страниц, капча, форум, перевод фрагментов текста на русский язык (с локализацией беда вообще), управление комментариями, красоты всякие аджаксовые… А элементарный файловый менеджер? Попробуй его найди. Опять — ставить плагин… И просто попытка загрузить на свой же сайтоблог файлик, чтобы показать другу, превращается в мучение.
4. Слишком большое количество файлов. Как следствие — бóльшая уязвимость системы (то, что это вордпресс, фактически невозможно скрыть: слишком много следов). Логика, конечно, предельно понятная, сразу знаешь, что где искать, но нужно ли, если как фреймворком пользуешься вордпрессом as is?

Итог. В качестве системы, которую быстро поставил, настроил и работай — очень удобно. Если нужна серьёзная основа для работы с большим наплывом пользователей — нужно ещё тринадцать раз подумать.

Исходная публикация: blog.erlang.com.ru/post.php?2009-5-16

Проектирование и реализация веб-приложений, требующих интенсивной работы процессора, — задача не из числа тривиальных. В теории все знают, что если сервер не справляется с требуемым объемом вычислений за определенное время, то нужно разбить задачу на мелкие и обрабатывать ее части параллельно на нескольких машинах. Этот подход известен как распределенные вычисления. Распространено мнение, что как разработка, так и поддержка серверного решения распределенных систем — трудоемкий и дорогой процесс, что является серьезным барьером для стартапов. В этой статье мы развеем этот миф, предложив практическое решение для такой задачи:

— данные для обработки поступают от заказчиков в виде задач через web в течение рабочего дня, однако обрабатывать их нужно в ночное время (например, с 00:00 до 06:00);
— объем входных данных для обработки задачи, как и данных, представляющих результат, невелик (например, несколько килобайт);
— все задачи и результаты должны быть зарегистрированы в единой базе;
— обработка задачи требует значительного времени в масштабах среднестатистического веб-сервера (например несколько секунд);
— количество задач, которые нужно обработать за ночь, довольно большое (тысячи).

Hardware: Серверное решение

Серверное решение базируется на том, что главный сервер круглосуточно собирает данные от пользователей и передает их на обработку другим серверам, специально подобранным и сконфигурированным для выполнения ресурсоемких вычислений (таких серверов может быть десятки или сотни). Вычисления производятся на этих серверах ежедневно в ночное время, как требует поставленная задача.

Организация подобной системы довольно затратна, поскольку требуется приобрести, настроить и поддерживать достаточное количество серверов. Кроме того, налицо неэффективное использование ресурсов — вычислительные серверы будут простаивать в дневное время. Если требуется обеспечить запас мощности (например, возможно некоторое колебание дневного объема задач), то нужно иметь определенное количество серверов в резерве.

Учитывая требования к системе, мы предлагаем использовать сервис Amazon EC2 как хостинг-платформу для вычислительных серверов. Преимуществом этой платформы являетется то, что возможен динамический запуск виртуальных машин, причем оплате подлежат фактические часы использования. Если программная логика позволяет динамически оценить количество требуемых машин для обработки данных за ночь, то можно без участия человека запускать требуемое количество машин, разворачивая их из подготовленного образа. Когда вычисления закончены, разумно остановить все машины, чтобы не оплачивать время простоя.

Для работы с виртуальными серверами доступен API и множество реализующих его библиотек. В своей работе мы используем Amazon EC2 API Tools. Однако детальное рассмотрение возможностей API выходит за рамки данной статьи. Для главного сервера подходит мощный сервер как на традиционном хостинге, так и на Amazon EC2.

Software: Архитектура

Назовем модуль, работающий на главном сервере, DCBoss, а внешний модуль, установленный на вычислительных серверах, — DCWorker. Функция DCWorker проста — он получает задачу (или пакет задач) на обработку, производит вычисления и возвращает результат DCBoss.

Рассмотрим задачи DCBoss более детально. Главный модуль ответственен за следующие процедуры:

1. получение данных от заказчиков;
2. распределение задач между копиями DCWorker, контроль выполнения;
3. получение результатов от DCWorker и сохранение в центральной базе.

Рисунок 1

Вторая задача довольно нетривиальна, но вполне стандартна. Чтобы не изобретать велосипед, мы использовали готовое решение — Amazon SQS, которое берет на себя разрешение вопросов диспетчеризации задач (блокировка задачи во время ее выполнения одной из копий DCWorker, повторная отправка задачи на выполнение в случае неуспешного завершения первой попытки и т.п.). Кроме того, в силу своей распределенной природы, Amazon SQS успешно справляется с тысячами одновременных запросов на получение новой задачи (в случае большого числа копий DCWorker).

Таким образом, мы пришли к модифицированной схеме процесса, где DCBoss выполняет следующие функции:

1. получение данных от заказчиков;
2. отправка задач в очередь на базе Amazon SQS (назовем ее TaskQueue);
3. получение результатов от DCWorker и сохранение в центральной базе.

Рисунок 2

В получившейся схеме все же присутствует одно слабое место — получение результатов от DCWorker, которое может оказаться массовым. Чтобы избежать ситуации пиковых нагрузок на главный сервер, мы ввели в схему еще одно звено — вторую очередь на базе Amazon SQS, в которую DCWorker сохраняет результаты вычислений. Назовем эту очередь ResultQueue. DCBoss сам инициирует чтение результатов вычислений из ResultQueue, что позволяет избежать ситуации массовых обращений к главному серверу копиями DCWorker.

В данной схеме DCBoss ответственен за такие функции:

1. получение данных от заказчиков;
2. отправка задач в TaskQueue;
3. получение результатов из ResultQueue и сохранение их в центральной базе.

Рисунок 3

При введении в систему элементов на базе Amazon SQS следует учитывать некоторые особенности этой реализации очереди.

— Принцип FIFO не соблюдается, и элементы возвращаются очередью в случайном порядке. Для нашей задачи это не принципиально, так как в момент запуска вычислений прием новых задач от заказчиков приостанавливается, и рассчитанные вычислительные мощности должны справиться с поступившими задачами.
— Amazon SQS гарантирует, что элемент очереди будет возвращен не менее одного раза, что означает вероятность обработки одной задачи несколькими копиями DCWorker.
В результате мы добились довольно гибкой схемы, где есть возможность управлять вычислительными мощностями за счет изменения количества копий DCWorker.

Software: Реализация

DCBoss и DCWorker — это два независимых модуля, которые могут быть реализованы на разных языках программирования и/или запущены на разных платформах, поскольку они взаимодействуют между собой только через Amazon SQS API. Мы выбрали для реализации соответственно Java и PHP, поскольку для них доступны библиотеки, реализующие SQS API. Хотя, конечно, можно реализовать все необходимые функции самостоятельно и на другом языке.

TaskQueue и ResultQueue оперируют с текстовыми сообщениями, представляющими задания и результаты. У Amazon SQS есть ограничение: длина сообщения не должна превышать 8kb. Если такое ограничение неприемлемо для системы, то обойти его можно, как рекомендует Amazon: «Сообщения большего размера можно хранить на Amazon Simple Storage Service (Amazon S3) или Amazon SimpleDB и использовать Amazon SQS для хранения указателя на объект Amazon S3 или Amazon SDB». [http://docs.amazonwebservices.com/AWSSimpleQueueService/2008-01-01/SQSGettingStartedGuide/]. С другой стороны, если, к примеру, объем сообщения не превышает 1kb, то можно оптимизировать передачу данных за счет объединения 8 заданий (или результатов) в пакет.

Демонстрационная система

Мы предлагаем исходный код простой реализации модулей DCBoss и DCWorker. Данная реализация нацелена на подтверждение концепции и визуализацию идеи. Применение ее на практике потребует по меньшей мере реализации обработки исключительных ситуаций.

Модуль DCBoss реализован как веб-приложение на Java, основанное на веб-оболочке Struts и библиотеке Typica для работы с Amazon SQS API. DCBoss позволяет пользователю создавать тестовую «задачу» и «запускать ее на выполнение» с возможностью наблюдать все этапы обработки. В демонстрационной системе пользователь вручную инициирует запуск копий DCWorker. Пользователь может получить информацию о том, какая из копий DCWorker обработала определенную задачу.
DCWorker — это скрипт на PHP с заглушкой на месте предполагаемой обрабатывающей функции. Здесь используется библиотека simple-aws для работы с Amazon SQS. DCWorker просто читает задачи из TaskQueue и помещает сообщения с добавлением своего идентификатора в ResultQueue. Для простоты копии DCWorker — всего лишь экземпляры PHP-класса, эмулирующие работу виртуальной машины и выполняющие обработку на одном сервере как обработчики HTTP-запросов.

В приложенном файле readme.txt можно найти информацию о том, как настроить оба модуля.

Современные технологии позволяют сделать даже масштабные по объемам вычислений решения вполне доступными. Amazon предоставляет целый ряд мощных средств для их реализации — Amazon SQS и Amazon EC2, рассмотренные в этой статье — только примеры, которые мы успешно применяем в нашей работе.

Исходный код

Автор: Екатерина Журданова

Замечание: Для простоты мы будем хранить пользователя (объект) в http-сессии.

Одним из решений такой проблемы является проверка внутри каждого экшна (хранится ли в сессии такой-то пользователь), но это неэкономно. Гораздо удобнее осуществлять подобную проверку до вызова экшна. Подобный подход в Struts 2 реализуется с помощью механизма перехватчиков, или интерцепторов (interceptors).

Как видно из простой схемы (см. иллюстрацию выше), перехватчики могут выполняться до и/или после выполнения экшнов. В результате своей работы перехватчик может вызвать действие, или предотвратить его выполнение, или перенаправить дальнейшую обработку третьему действию. Все перехватчики, так же как и экшны, складываются в стек и выполняются в указанном порядке, поэтому подряд могут выполняться сразу несколько интерцепторов.

Хранение пользователя в сессии
Это отступление необходимо, т.к. позволит сократить дальнейшие объяснения по реализации собственного интрецептора, но останавливаться на них подробно не будем. Все изменения несложные и очевидные.
Сначала создаем класс User:

public class User implements Serializable {

	private String nick;
	private String password;

    public User(String nick, String password){
        this.nick = nick;
        this.password = password;
    }
	public String getNick() {
		return nick;
	}
	public void setNick(String nick) {
		this.nick = nick;
	}

	public String getPassword() {
		return password;
	}
	public void setPassword(String password) {
		this.password = password;
	}
}

Создаем класс <code>AuthController</code>, отвечающий за помещение объекта User в сессию с некоторым ключом и извлечение из сессии по тому же ключу:

public class AuthController {

	private static final String SESSION_KEY = "authUser";

	public static User getUser() {
		return (User)ActionContext.getContext().
getSession().get(SESSION_KEY);
	}

	public static void setUser(User user) {
		ActionContext.getContext().getSession().
put(SESSION_KEY, user);
	}
}

Исправляем LoginAction:

//добавляем поле user типа User
private User user;
....
//исправляем валидацию с учетом появления нового объекта
public void validate() {
		if (!this.getFieldErrors().isEmpty()) return;
        this.user = new User(this.getNick(),this.getPassword());
		if (!"user".equalsIgnoreCase(this.user.getNick()) ||
 !"user".equalsIgnoreCase(this.user.getPassword()))
	    	this.addFieldError("invalidLoginPassw",
 "Invalid login/password");       

	}
...
//кладем user в сессию, если валидация пройдена
public String loginSubmit() throws Exception {
		AuthController.setUser(this.user);
		return SUCCESS;
	}

ActionInvocation
Когда фреймворк получает запрос от клиента, он в первую очередь решает, какой экшн нужно выполнить. Но вместо того, чтобы выполнять действие напрямую, создается объект ActionInvocation, который инкапсулирует экшн и интерцепторы, выполняемые до и/или после выполнения действия. Вообще ActionInvocation инкапсулирует все детали обработки текущего действия.

Итак, в начале обработки создается экземпляр класса соответствующего экшна. Этот экземпляр помещается в новый экземпляр ActionInvocation. Информация об экшне, как мы помним, берется из struts.xml. Из того же конфигурационного файла получаем информацию об интерцепторах, которые связаны с этим действием, и об их порядке (что именно добавляется в struts.xml, покажем ниже). Ссылки на перехватчики в нужном порядке так же добавляются к ActionInvocation. ActionInvocation отвечает за последовательный вызов и выполнение перехватчиков из стека, вызывая у каждого из них метод intercept(). Заметим, что этот метод содержит ActionInvocation в качестве параметра. После выполнения всех перехватчиков из стека вызывается выполнение экшна (фреймворк вызывает метод invoke()). В общем случае ActionInvocation проходит весь стек перехватчиков и передает дальнейшую обработку экшну, пришедшему от клиента. Выполнение действия происходит так же, как мы рассматривали в первом уроке.

Создание собственного перехватчика
Вначале создаем абстрактный класс ActionBase, который содержит всего одно поле checkAuth:

public abstract class ActionBase extends ActionSupport {

	private boolean checkAuth;

	public boolean isCheckAuth() {
		return checkAuth;
	}
	public void setCheckAuth(boolean checkAuth) {
		this.checkAuth = checkAuth;
	}

}

Это поле checkAuth отвечает за то, нужно ли для данного экшна проверять наличие пользователя в сессии.

Все классы, обрабатывающие экшны в примере, должны наследовать этот абстрактный класс.

Теперь переходим к самому перехватчику.
Наш класс должен наследовать интерфейс Interceptor, от которого нужно реализовать метод intercept():

public class AuthenticationInterceptor implements Interceptor {

	public String intercept(ActionInvocation actionInvocation)
 throws Exception {
		Object action = actionInvocation.getAction();
		if (action != null && (action instanceof ActionBase) &&
(ActionBase)action).isCheckAuth()) {
			if (AuthController.getUser() == null)
				return "redirectToLogin";
		}
		return actionInvocation.invoke();
	}
	...
}

Метод intercept() принимает ActionInvocation в качестве параметра, из которого получаем Action. Перехватчик проверяет, свойство экшна checkAuth и наличие пользователя в сессии. Если для полученного экшна не нужно выполнять проверку или пользователь найден в сессии, то интерцептор передает управление первоначальному экшну. Иначе интерцептор возвращает строку «redirectToLogin».

На первом занятии мы выяснили, что для каждого экшна в struts.xml определен результат, например:

 <result type="dispatcher" name="success">/WEB-INF/jsp/login.jsp</result> 

Какой именно результат (а их может быть несколько) будет выполняться, указывается параметром name. Интерцептор в любом случае тоже должен вернуть какой-либо результат. В случае, если пользователь не найден в сессии, возвращается строка. По этому значению фреймворк будет искать соответствующий результат в struts.xml. Однако результат, который мы пытаемся получить, не относится к какому-либо экшну, а определен независимо от них и называется global result. Определяется global result так:

<global-results>
    <result type="redirect" name="redirectToLogin">login.action</result>
</global-results>

Как видим, в результате произойдет редирект на login.action.

Поскольку обработка экшнов начинается с обращения к struts.xml, то наш интерцептор также должен быть указан в этом файле:

<interceptors<
   interceptor name="checkAuthInterceptor"
     class="mymovieteach.interceptor.AuthenticationInterceptor"/>
    <interceptor-stack name="defStack" >
       <interceptor-ref name="defaultStack" />
       <interceptor-ref name="checkAuthInterceptor" />
    </interceptor-stack>
</interceptors>

Все, что касается перехватчиков, определяется внутри тега <interceptors>. Тегом <interceptor> мы определяем свой собственный интерцептор. Атрибут name, очевидно, отвечает за имя интерцептора, а атрибут class — за полное имя класса, его обрабатывающего.

С помощью тега <inteceptor-stack> мы задаем стек перехватчиков, перечисляя их по имени. Первым в стеке указан defaultStack, он предоставляется самим фреймворком и отвечает, например, за доставку параметров в экшн и загрузку файлов. Следом указан определенный выше перехватчик checkAuth.

Остался последний шаг. Укажем в struts.xml значение параметра checkAuth=true для home.action:

<action name="home" class="mymovieteach.action.HomeAction"
method="show">
    <param name="checkAuth">true</param>
    <result type="tiles">home</result>
</action> 

Таким образом, интерцептор будет выполнять свою проверку только для этого экшна. Для login.action проверка не имеет смысла, поэтому интерцептор сразу передаст управление самому экшну.

Приложение 1:
полный листтинг конфигурационнго файла struts.xml

<struts>
<package name="common" extends="tiles-default">
  <interceptors>
      <interceptor name="checkAuthInterceptor"
        class="mymovieteach.interceptor.AuthenticationInterceptor"/>
        <interceptor-stack name="defStack">
           <interceptor-ref name="defaultStack" />
           <interceptor-ref name="checkAuthInterceptor" />
        </interceptor-stack>
  </interceptors>
  <default-interceptor-ref name="defStack"/>
  <global-results>
      <result type="redirect" name="redirectToLogin">login.action</result>
  </global-results>
  <action name="login" class="mymovieteach.action.LoginAction" method="input">
      <result type="tiles">login</result>
  </action>
  <action name="loginSubmit" class="mymovieteach.action.LoginAction"
      method="loginSubmit">
      <result type="tiles" name="input">login</result>
      <result type="redirect">home.action</result>
  </action>
  <action name="home" class="mymovieteach.action.HomeAction" method="show">
      <param name="checkAuth">true</param>
      <result type="tiles">home</result>
  </action>
</package>
</struts>

Приложение 2:
полный листинг класса AuthenticationInterceptor

package mymovieteach.interceptor;

import mymovieteach.action.ActionBase;
import mymovieteach.auth.AuthController;
import com.opensymphony.xwork2.ActionInvocation;
import com.opensymphony.xwork2.interceptor.Interceptor;

public class AuthenticationInterceptor implements Interceptor {

	public String intercept(ActionInvocation actionInvocation) throws Exception {
		Object action = actionInvocation.getAction();
		if (action != null && (action instanceof ActionBase) &&
((ActionBase)action).isCheckAuth()) {
			if (AuthController.getUser() == null)
				return "redirectToLogin";
		}
		return actionInvocation.invoke();
	}

	public void init() {
	}

	public void destroy() {
	}
}

Упражнение 1
Предлагаем вам на основе всех четырех уроков самостоятельно добавить в приложение регистрацию пользователей. Для определенности считаем, что на форме регистрации должны быть следующие поля: ник, пароль, подтверждение пароля, email и чекбокс «I agree with terms and conditions».

Исходный код примера вы найдете в архиве (см. ниже). Здесь реализованы не только авторизация пользователя, но и регистрация. Вы можете подсмотреть код при выполнении упражнения, если возникнут какие-либо проблемы или трудности.

Исходный код к уроку (и упражнению)

Имена таблиц

— В именах таблиц используются только строчные буквы.

men

— Имена в многословных названиях разделяются подчеркиванием.

user_details

Имена полей

— В именах полей используются только строчные буквы.
— Шаблон: {3-буквенный префикс по имени таблицы}_{название поля или название поля на которое ссылаемся}
Пример

Таблица name
Поля:
nam_id — int
nam_name — varchar(255)

Таблица men
Поля:
men_id — int
men_nam_id — int
men_men_matherId — int
men_men_fatherId — int

Как читать

1) name — говорит что это таблица. Например v_name —это уже VIEW

2) nam_id — «nam»– это 3-буквенный префикс, он один на все таблицу и должен быть уникальным, как и имя таблицы. nam_id – идентификатор записи в таблицы name.

3) men_nam_id — тут мы читаем как: поле из таблицы men (нам об этом говорит префикс «men») и что оно ссылается на поле nam_id из таблицы nam

4) Нам нужно сделать две ссылки на таблицу nam — men_men_matherId и men_men_fatherId, которые будут ссылатся на одно и тоже поле man_id, но не можем сделать два поля с одинаковым именем mem_men_id, поэтому мы перед id подписывает уточнения: mather и father.

Типы таблиц и кодировки

Все приложения разрабатываемый для клиентов рано или поздно требуют поддержку unicode поэтому таблицы должны изначально ее поддерживать. Для поддержки транзакций таблицы должны быть типа InnoDB

CREATE TABLE `letter` (

  `ltr_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,

  `ltr_title` char(255) NOT NULL,

  `ltr_shortdescription` text NOT NULL,

  `ltr_cmp_id` int(11) DEFAULT NULL,

  PRIMARY KEY  (`ltr_id`),

  UNIQUE KEY `ltr_id` (`ltr_id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8

Имена файлов, пакетов

— В именах пакетов используются только строчные буквы.

staffavailability

— Имена Java-классам даются согласно стандартной нотации Java.

StaffAvailability

— Имена классов должны быть существительными, первые буквы всех слов — заглавные.
— В именах web-папок и файлов используются только строчные буквы. Слова в многословных названиях разделяются подчеркиванием.

staff_availability

Имена методов, переменных

— Названия методов должны быть глаголами, первая буква должна быть строчной, первые буквы внутренних слов — заглавные.
— Имена переменных должны начинаться со строчной буквы, внутренние слова — с заглавной.
— Имена констант составляются из всех заглавных букв, разделенных на слова символом подчеркивания.

Отступы, длина строки, переносы строк

— Отступы должны составлять строго 4 пробела (не знак табуляции).
— Длина строки не должна превышать 80 символов.
— Если длина выражения превышает длину строки, то необходимо разбить его на несколько строк согласно следующим правилам:
1. перенос после запятой;
2. перенос перед оператором;
3. необходимо использовать отступ 8 пробелов для обозначения второй строки разделенного выражения. Последующие строки выравниваются по второй строке либо добавляются новые 8 пробелов для обозначения вложенности.

int result = function1(longExpression1,

         function2(longExpression2,

                longExpression3));

Расположение блоков, операторов, пробелы, скобки

— Определение переменных нужно располагать в начале блока, а не «ждать» первого использования переменной. Инициализация должна производиться, по возможности, сразу.

void myMethod() {

    int count  = 0; // beginning of method block

    if (condition) {

        int int2; // beginning of "if" block

        ...

    }

}

- Между именем метода и скобками для списка параметров нет пробела.

getStaffList(String name)

— Параметры разделяются пробелом.

getStaffList(String name, int count)

— Пробелы окружают любой оператор.

res = getCount();

(a > 10) ? b : c;

— Ключевое слово и следующая за ним скобка ( должны разделяться пробелом.

while (b < 100){

    …

}

— Открывающаяся скобка { располагается на той же строке, что и сигнатура метода/заголовок if, while-блока и т.п.
— Закрывающаяся скобка } выровнена по строке начала данного блока.

public Collection getStaffList(String name) {

    	Collection contacts = Contact.getList(name, RoleHelper.ROLE_AGENT, null,

    			AccessLevel.getStaffDiaryEditLevel(), 0, MAX_NUMBER);

    	return ListHelper.getLabelValueList(contacts);

    }

— Методы разделяются пустой строкой, объявления свойств класса располагаются по одному на строку.
— На строке располагается только один оператор.

if (b) {

    return result;

}

Структурирование кода

— Методы должны быть короткими, и выполнять только одну задачу (к примеру, почти любой цикл уже достоин того, чтобы вынести его в особый метод).
— Имена методов должны быть самодокументированными.
— Шаблоны ООП должны применяться для структурирования и облегчения восприятия.

Стандарт разработан на основе “Code Conventions for the Java Programming Language” by Sun (http://java.sun.com/docs/codeconv/) с учетом принятых в коллективе практик.

Семантическая вёрстка

Часто термин «семантическая вёрстка» используют не совсем корректно, в плане просто отделения формы от содержимого. Допустим, есть страница, свёрстанная на блоках, а всё разукрашивание ведётся средствами CSS. Логика и оформление в этом случае разделены, но при одном условии: если идентификация блоков ведётся не по внешним признакам, а действительно по семантике. Распространённая ошибка многих веб-верстальщиков — использовать идентификаторы и классы по их верстальным возможностям. Например, специальный блок для завершения группы плавающих элементов. Span, выделяемый красным цветом. Одинаковый класс и для эпиграфа, и для авторской подписи к материалу (выравнивание по правому краю + курсив). Чем это плохо: если возникнет необходимость изменить стилевое описание элементов, используемых на одной странице, то есть опасность, что «поедет» вёрстка или проявятся нежелательные изменения на страницах другого типа, где применены те же классы. (При редизайне установили для блока ширину в 415px вместо 512, но не проверили, что на одной из страниц из-за этого съёжились поля для ввода и лейблы, заключённые в блок с тем же стилевым идентификатором).

Принципы правильной вёрстки

1. Использовать только смысловые имена. Если блок для формы регистрации и блок для отправки писем похожи по каким-то признакам или на данном этапе вообще обладают одинаковыми стилями, лучше сделать два идентичных описания, но для разных ID или классов. В будущем вы обезопасите себя от багов в вёрстке, случившихся по недосмотру.

2. Если стилей получается слишком много, можно использовать несколько стилевых файлов: один основной, для классов и идентификаторов, встречающихся на большинстве страниц, остальные по разделам. Соответственно и подгружать нужные в соответствующих разделах (это легко поручить серверу).

3. Целесообразно использовать префиксы в именах классов и идентификаторов, например: regform_main, regform_input, regform_label, regform_announcement и так далее (помимо всего прочего, это создаст удобства при динамическом изменении стилей средствами JavaScript или серверного языка).

В стилевых файлах очень удобно снабжать комментариями разделы, например:

/* Main */

a { ... }

p { ... }

/* Forms */

input { ... }

input.abcd { ... }

/* IDs */

#abc { ... }

#pretend { ... }

Старайтесь использовать в стилевых файлах только латиницу во избежание проблем некоторых браузеров в кодировкой: если страница на UTF, а стилевой файл на Windows-1251 с использованием кириллических символов, то Internet Explorer (до 6 версии точно) просто проигнорирует эту стилевую таблицу.

И, конечно, нужно использовать последовательный стиль вёрстки и написания стилевых файлов: отступы, особенности имён, стилевые правила в столбик или в строчку…

4. Можно в качестве вспомогательных мер использовать возможности наследования, или вложенности, как некий аналог ООП. Если я напишу:

div#register input {...},

то я буду точно уверен, что таким стилевым описанием я разукрашу только поля ввода, заключённые в блок с id=”register”, а не какие-либо другие.

А для всех полей ввода можно описывать общие правила, только если они точно и всегда будут соблюдаться на всех страницах сайта и соответствуют общему стилю.

5. И не нужно забывать про таблицы. Их некто не отменял, если они также используются семантически, то есть для табличных данных (статистика, результаты, цены и т. п.)

Код на CSS

1. CSS-файл с помощью комментариев разбивается на разделы:

• основное (*, p, a, формы и т.п.),
• идентификаторы и классы, которые встречаются на всех страницах,
• разделы по конкретным страницам или группам страниц

В этом случае проще найти причинно-следственные связи глюков вёрстки

2. Стандарт оформления одного стилевого описания:

селектор {

 правило 1;

 правило 2;

 правило 3;

 }

Не забываем о точке с запятой, несколько раз исправлял; это в некоторых браузерах бывает критично.

3. Желательное расположение правил в описании:
селектор {
блочные правила (display, position, z-index, top, right, float, clear);
правила, относящиеся к блокам (margin, padding, border, width, height);
линейные правила (цвет и гарнитура текста, подчёркивание);
разное (курсоры и т. п.)
}
4. Единицы измерения пишем вплотную к числам: в некоторых браузерах из-за пробела возникнут разночтения.

5. В начале CSS-файла обнуляем все отступы.

* {

 margin:0;

 padding:0;

 border:0; /* Если не нужны рамки для элементов форм */

 }

Затем в каждом конкретном случае назначаем отступы и рамки индивидуально. В этом случае у нас ничего не едет в разных браузерах.
6. Ограничения

С помощью CSS невозможно описать некоторые вещи, чтобы они корректно отображались во всех браузерах. Для их эмуляции можно использовать графику и обходные пути, это чуть дольше (учитывать эти трудозатраты при обсуждении предложенного дизайна интерфейса), но реально.

Чекбоксы. В Опере можно настроить цвета и размеры, в ИЕ частично (объёмная рамка остаётся всегда), ФФ игнорирует CSS для чекбоксов. Если нужно кардинально менять внешний вид, решение такое: блок с чекбоксом делать с position:relative, внутри блока до самого input ставить span с такими же размерами, как у блока с чекбоксом, но абсолютно позиционированный, а фон span’а в CSS написать и скриптом менять в зависимости от нажатия. При отсутствии картинок будут видны чекбоксы (если не прописать цвет фона, конечно), при наличии — заменители.

Радиобаттоны (переключатели). То же самое, что и для чекбоксов. При CSS-изменении фона в Опере фон меняется внутри поля, в ИЕ вокруг него, в ФФ не меняется.

Поля для загрузки файлов. Наименее поддающаяся правке часть формы. В ФФ даже нельзя регулировать длину поля, во всех браузерах внешний вид кнопки Browse/Обзор не редактируется, надпись зависит от языка браузера, на border все браузеры реагируют по-разному: кто рисует вокруг поля ввода, кто целиком обрамляет поле ввода + кнопку, кто игнорирует. Решение: поле сделать прозрачным:

 filter:progid:DXImageTransform.Microsoft.Alpha(opacity=50); /* IE 5.5+*/

 -moz-opacity: 0.5; /* Mozilla 1.6 и ниже */

 -khtml-opacity: 0.5; /* Konqueror 3.1, Safari 1.1 */

 opacity: 0.5; /* CSS3 - Mozilla 1.7b +, Firefox 0.9 +, Safari 1.2+, Opera 9 */

Под поле положить поле ввода и нарисованную кнопку, точно позиционировав их, а поле для загрузки выровнять по правому краю. Получится, что при щелчке на видимой нарисованной кнопке на самом деле будет происходить щелчок по прозрачной кнопке, а информацию о выбранном файле нужно скриптом записывать в редактируемое видимое поле ввода.

Выпадающие списки. Нормально редактируются в ФФ и Опере, в ИЕ остаётся объёмный край. Тэг optgroup, группирующий элементы option, во всех браузерах интерпретируется по-разному и не редактируется CSS.

Позиционирование. При вставке флэш-объекта он всегда оказывается на переднем плане, даже если есть элемент с z-index:40000. Решение только в правильном построении блока embed/object:

#flash {

  position: relative; /*or absolute*/

  z-index: 0;

}

<div id="flash">

  <object ...>

    <param name="wmode" value="opaque">

    <embed ... wmode="transparent">

  </object>

</div>

Фоновые изображения. Желательно указывать не только картинку, но и цвет фона, чтобы без графики у блока не было прозрачного фона. В URL не надо использовать кавычки: IE 5 под Макинтошем, встретив их, вешается.

Код на HTML

Если ориентируемся на XHTML-вёрстку, в одиночных тэгах завершающий слэш ставим через пробел: <br /> — это нужно для корректного их чтения старыми браузерами. Нетскейп 4 и прочая архаика не знает тэга <br/> (без пробела), но корректно проигнорирует неизвестный атрибут / тэга <br>, а для новых браузеров всё равно, есть пробел или нет. Одиночные тэги: <img />, <br />, <hr />, <input />, <meta />, <link />, <base /> (последний не поддерживается спецификацией). В выпадающих списках всегда закрываем <option>вот так</option>. Не закрывать тэги и писать их большими буквами — хамство (© Катя Журданова).

Для всех элементов форм используем и name, и id — если не нужно сразу, пригодится в дальнейшем.

Если чекбокс один в форме, то имя и идентификатор могут совпадать.

Для чекбоксов и радиобаттонов используем лейблы:

<input type="checkbox" name="checkbox1" id="checkbox1" value="1" />
<label for="checkbox1">Нажимать тут</label>

Желательно и для остальных полей ввода использовать не абстрактные блоки или span, а лейблы (<label>) — с помощью стилей их легко сделать и строчными, и блочными элементами, и в любом браузере они легко разукрашиваются.

Не гнушаемся абзацами. Часто так получается, что все мыслимые текстовые фрагменты заключены в «дивы», а для очистки от флоатинга потом используется <br> с каким-нибудь классом. Если использовать <p>…</p> с содержимым в нужных местах, а в стилях для абзацев назначить clear:both, то можно избежать ненужного мусора в коде.

Использование ссылок и «системных спэнов». Не очень хорошая практика: вешать onClick на ссылку, которая никуда не ведёт. С точки зрения интерфейса — эффект обманутого ожидания, плюс некоторые пользователи смотрят в статусную строку или на всплывающую подсказку и видят, что со ссылкой что-то не то. Современная практика: делать span с особым классом, визуализирующийся как текст цвета ссылки, подчёркнутый прерывистой линией (dashed), чтобы было похоже на ссылку, но лишь отчасти. Это не правило, но серьёзная рекомендация. Для span можно использовать атрибут title, который будет выполнять роль всплывающей подсказки.

Запрет кэширования. В большинстве случаев достаточно пары тэгов:

<meta http-equiv="Pragma" content="no-cache">

<meta http-equiv="Expires" content="0">

Хотя бы на время отладки приложений.

При выделении (эмфазисе) фрагментов текста вместо тэгов <b> и <i> используем <strong> и <em>, если это действительно семантически оправдано и нет смысла делать спэны с классами. Такая замена соответствует спецификации XHTML и будущим стандартам HTML 5 (отказ от визуального форматирования в пользу логико-семантического).

Если используем таблицы, избавляемся от <thead> и <tbody>, если вдруг они невзначай генерируются редактором. Это устаревшие элементы.

После того, как мы ознакомились с классами в Motools, можно (и нужно) рассмотреть конкретный пример.
Пусть на странице есть div, внутри него текст, который не должен превышать 20px в высоту. Если текст не умещается в эту высоту, то его нужно скрыть до нужной высоты и в конце видимой части текста добавить ссылку «…more». Щелкаем по ссылке — видим текст целиком.

Итак, на странице есть нужный div:

<div id="detlongDescription" style="width:500px">За последние десятилетия интерес к артистам, практикующим искусство голодания, сильно упал. И если раньше было очень даже выгодно устраивать крупные представления подобного рода за собственные средства, то сегодня это совершенно невозможно. Тогда были другие времена.</div>

Напишем mootools-класс, который будет получать в конструктор id того блока, в котором находится текст и обрабатывать его.

Приступим теперь к реализации компонента. Создаем свой класс, назовем его SLDescription. Как это будет работать:
1. Создается экземпляр класса: вызывается конструктор initialize, куда передаем id блока с нужным текстом. Так же в конструкторе инициализируются дополнительные свойства класса: высота блока (у нас это 20px), которую не должен превышать div с текстом, и текст ссылки на полный вариант текста.
2. На загрузку страницы у созданного объекта вызывается метод start(). Здесь происходит следующее:
— определяются координаты блока с текстом на странице и проверяется, превышает ли он допустимую высоту (ту, что определили в конструкторе);
— если не превышает, то ничего не делаем;
— если блок превышает указанную высоту, то сохраняем полный текст в некоторое поле объекта, также разбиваем текст внутри блока на слова и храним эти слова в виде массива. Затем содержимое блока очищается. Далее сокращенный вариант текста собирается по одному слову до достижения нужной высоты. Здесь есть одна особенность. Нам нужно, чтобы в нужную высоту вписался часть текста вместе со ссылкой на полный вариант, поэтому вначале к div’у добавляется новое слово + название ссылки. Затем проверяется, не достигли ли мы нужной высоты. Если достигли, то на этом выходим из цикла по массиву слов, а если не достигли, то добавляем только слово из массива к сокращенному тексту (не забываем, что кроме слов нужно восстанавливать пробелы между ними).
Выйдя из цикла, помещаем внутрь div’a сокращенный текст + ссылку.

Реализуем сначала упрощенный вариант нашего алгоритма. Считаем, что не нужна нам пока никакая ссылка и никакой полный вариант текста тоже пока не нужен, а будем добавлять в конце сокращенного текста только надпись «…more». Итак, приступаем к написанию класса:

var SLDescription = new Class({
	initialize: function(divId) {
		//задаем свойства объекта
		this.divId=divId;
		//задаем высоту блока с текстом
		this.baseHeight=20;
		this.moreText = "...more";
},
start:function() {
        	var coordinates=null;
		//получаем фактические координаты div'а
        	coordinates= $(this.divId).getCoordinates();
		//разделяем текст на массив слов
		var splitText=$(this.divId).innerHTML.split(' ');
		$(this.divId).innerHTML='';
		var limit=true;
		var i=0; //количество показанных слов
		var text="";
		this.shortText="";
		//собираем сокращенный вариант текста по словам
		for( i=0; ithis.baseHeight){
				limit=false;
			// превысили высоту div'а, поэтому заканчиваем цикл
			}
			else {
				this.shortText=text;
			}
		}
		// помещаем сокращенный текст внутрь элемента
		$(this.divId).innerHTML=this.shortText;
		// если закончили текст раньше,
		// чем закончились слова в массиве,
		// то добавляем к тексту еще надпись
		if (i<splitText.length)
			$(this.divId).innerHTML+=this.moreText;
	}
}).

Посмотреть, как работает.

До сих пор нигде не встречалась конструкция $(...). На самом деле выражение $('elemId') в Mootools возвращает ссылку на элемент в DOM, у которого id='elemId'. Это тоже самое, что и document.getElementById('elemId'). Кроме того, еще мы вызываем такие методы у элемента, как getStyle(...) и getCoordinates(...), но останавливаться подробно на них не будем, т.к. очевидно, что они делают. Более подробные сведения и описание вообще всех методов элементов в Mootools можно найти на сайте с документацией по Mootools.

Теперь усложним наш класс. Будем теперь добавлять в конце текста именно ссылку, при щелчке по которой будет появляться весь текст целиком. В предыдущем варианте мы нигде не сохраняли первоначальный текст, т.к. не требовалось его показывать на странице. Теперь же прежде, чем разбивать текст на слова и выполнять дальнейшие действие, необходимо сохранить текст в его первоначальном виде. Для этого немного исправим метод start, заменив
...
var splitText=$(this.divId).innerHTML.split(' ');
...
на
...
this.longText=$(this.divId).innerHTML;
var splitText=this.lingText.split(' ');
...

Также вместо
...
if (i<splitText.length)
$(this.divId).innerHTML+=this.moreText;
...
появится
...
if (i<splitText.length)
this.addMore();
...

Теперь вместо того, чтобы просто добавить в конце текста только надпист «…more», будет вызываться метод, добавляющий ссылку «…more» на полный текст. Дописываем к нашему классу метод addMore:

...
addMore:function(){
	//создаем новый элемент в DOM
		var a = new Element('a', {
		    href: "javascript:;"
		});
		//добавляем событие к элементу
		a.addEvent('click', this.more.bind(this));
		//добавляем название ссылки
		a.appendText(this.moreText);
		//вставляем элемент внурь div'а
		a.injectInside($(this.divId));
	},
	...

Здесь поясним несколько моментов. Сначала мы с помощью специального объекта Mootools создаем новый элемент в DOM — ссылку, и указываем ее атрибут href. Затем, также с помощью функций Mootools, мы добавляем к созданному элементу событие onclick. Вообще метод addEvent принимает 2 параметра: тип события — строка с названием события без приставки on, и функция, вызываемая на это событие. В нашем случае, при нажатии на ссылку будет вызываться функция more() (её описание см. ниже), в которой переменная this будет ссылаться не на ссылку, а на экземпляр нашего класса SLDescription.

Поясним еще как работает метод injectInside(element). В нашем случае этот метод вставляет ссылку внутрь элемента с указанным id. Ссылка при этом допишется в конец содержимого element.

Наконец добавляем последний метод, который возвращает первоначальный текст (та самая функция, которая вызывается по щелчку на ссылке)

...
	more:function(){
		$(this.divId).innerHTML=this.longText;
	}

}) //закрывающие скобки для всего класса

Замечание: Рассмотрим такую ситуацию

			element.addEvent('click', fn1);
			...
			element.addEvent('click', fn2);

Возникает вопрос, какая функция вызовется на событие onclick. Правильный ответ — обе, т.к. события addEvent добавляет функцию к уже имеющимся, которые будут вызываться на обработку события.

Добавляем на страницу ссылку на скрипт, создание объекта и SLDescription и вызов у него метода start():

<script type="text/javascript" src="mootools.js"></script>
<script type="text/javascript" src="text_description.js"></script>
<script type="text/javascript">
	var desc=new SLDescription("detlongDescription");
	window.addEvent('load', function(){
		desc.start();
	});
</script>

Готово. Теперь все заработает так, как задумали вначале.

Полный текст скрипта text_description.js.

var SLDescription = new Class({
initialize: function(divId) {
		//задаем свойства объекта
		this.divId=divId;
		//задаем высоту блока с текстом
		this.baseHeight=20;
		this.moreText = "...more";
},
start:function() {
        	var coordinates=null;
		//получаем фактические координаты div'а
        	coordinates= $(this.divId).getCoordinates();
		//сохраняем первоначальный текст
		this.longText = $(this.divId).innerHTML;
		//разделяем текст на массив слов
		var splitText=this.longText.split(' ');
		$(this.divId).innerHTML='';
		var limit=true;
		var i=0; //количество показанных слов
		var text="";
		this.shortText="";
		//собираем сокращенный вариант текста по словам
		for( i=0; i<splitText.length&&limit; i++ ) {
			text+=(splitText[i]+" ");
			//текст должен укладываться в нужную высоту вместе со
			//ссылкой, поэтому перед проверкой
			//добавляем её вместе с текстом в div
			$(this.divId).innerHTML=(text+this.moreText);
			coordinates= $(this.divId).getCoordinates();
			if(coordinates.height>this.baseHeight){
				limit=false;//превысили высоту div'а, поэтому выходим из цикла
			}
			else {
				this.shortText=text;
			}
		}
		//помещаем сокращенный текст внутрь элемента
		$(this.divId).innerHTML=this.shortText;
		//если закончили текст раньше, чем закончились слова в массиве,
		//то добавляем к тесту ссылку
		if (i<splitText.length)
			this.addMore();
	},	

addMore:function(){
		//создаем новый элемент в DOM
		var a = new Element('a', {
		    href: "javascript:;"
		});
		//добавляем событие к элементу
		a.addEvent('click', this.more.bind(this));
		//добавляем текст, фактически это название ссылки
		a.appendText(this.moreText);
		//вставляем элемент внурь div'а
		a.injectInside($(this.divId));
	},

	//получить весь текст целиком
more:function(){
		$(this.divId).innerHTML=this.longText;
	}

});

Посмотреть, как работает.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE struts PUBLIC
    "-//Apache Software Foundation//DTD Struts Configuration
2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd">
<struts>
<package name="common" extends="tiles-default">
  <global-results>
    <result type="redirect" name="redirectToLogin">
      login.action</result>
  </global-results>
  <action name="login" class="mymovieteach.action.LoginAction"
   method="input">
    <result type="tiles">login</result>
  </action>
  <action name="loginSubmit" class="mymovieteach.action.LoginAction"
   method="loginSubmit">
    <result type="tiles" name="input">login</result>
    <result type="redirect">home.action</result>
  </action>
  <action name="home" class="mymovieteach.action.HomeAction"
   method="show">
   <result type="tiles">home</result>
  </action>
</package>
</struts>

Строка <package name="common" extends="tiles-default"> указывает на то, что для обработки экшнов используется пакет (package) common, наследующий функциональность tiles-default.
Благодаря такому наследованию в качестве типа результата можно указать значение tiles.
Рассмотрим пример. Происходит обращение к экшну login (детально процесс рассмотрен в предыдущих занятиях):

<action name="login" class="mymovieteach.action.LoginAction"
 method="input">
   <result type="tiles">login</result>
</action>

Выполняется метод input класса LoginAction (как мы помним, метод input не требует валидации); он возвращает SUCCESS, а значит, используется результат по умолчанию (он же единственный для данного экшна). Тип результата — tiles; значение — login.
В файле tiles.xml (приведен фрагмент) —

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE tiles-definitions PUBLIC
        "-//Apache Software Foundation//DTD Tiles Configuration 2.0//EN"
        "http://tiles.apache.org/dtds/tiles-config_2_0.dtd">
<tiles-definitions>
  <definition name="defaultLayout" template="/WEB-INF/jsp/layout/default.jsp">
    <put-attribute name="title" value=""/>
    <put-attribute name="leftTopPanel" value="/WEB-INF/jsp/inc/def_left_top_panel.jsp"/>
    <put-attribute name="leftBottomPanel" value=""/>
    <put-attribute name="rightTopPanel" value=""/>
    <put-attribute name="rightBottomPanel" value="/WEB-INF/jsp/inc/find_form_panel.jsp"/>
  </definition>
  <definition name="login" extends="defaultLayout">
    <put-attribute name="title" value="Login"/>
    <put-attribute name="leftBottomPanel" value="/WEB-INF/jsp/inc/join_left_bottom_panel.jsp"/>
    <put-attribute name="rightTopPanel" value="/WEB-INF/jsp/login_form.jsp"/>
  </definition>
  <definition name="home" extends="defaultLayout">
    <put-attribute name="title" value="Home"/>
    <put-attribute name="leftBottomPanel" value="/WEB-INF/jsp/inc/home_left_bottom_panel.jsp"/>
    <put-attribute name="rightTopPanel" value="/WEB-INF/jsp/inc/welcome_panel.jsp"/>
  </definition>
</tiles-definitions>

— содержатся строки, отвечающие за обработку данного типа результата:

<definition name="login" extends="defaultLayout">
  <put-attribute name="title" value="Login"/>
  <put-attribute name="leftBottomPanel" value="/WEB-INF/jsp/inc/join_left_bottom_panel.jsp"/>
  <put-attribute name="rightTopPanel" value="/WEB-INF/jsp/login_form.jsp"/>
</definition>

В этом фрагменте видно, что с помощью определений описываются три Tiles (title, leftBottomPanel и rightTopPanel). Но это описание наследует более общее описание Tiles по умолчанию (extends="defaultLayout"), в котором присутствуют пять атрибутов:

<definition name="defaultLayout" template="/WEB-INF/jsp/layout/default.jsp">
  <put-attribute name="title" value=""/>
  <put-attribute name="leftTopPanel" value="/WEB-INF/jsp/inc/def_left_top_panel.jsp"/>
  <put-attribute name="leftBottomPanel" value=""/>
  <put-attribute name="rightTopPanel" value=""/>
  <put-attribute name="rightBottomPanel" value="/WEB-INF/jsp/inc/find_form_panel.jsp"/>
</definition> 

Однако часть из них не заполнена значениями. Это значит, что для каждого конкретного экшна необходимо назначить значения для этих атрибутов (что и происходит в описании Tiles для экшна login). В итоге, если восстановить все значения, которые наследуются, то получится следующий набор значений:

<definition name="login" template="/WEB-INF/jsp/layout/default.jsp">
  <put-attribute name="title" value="Login"/>
  <put-attribute name="leftTopPanel" value="/WEB-INF/jsp/inc/def_left_top_panel.jsp"/>
  <put-attribute name="leftBottomPanel" value="/WEB-INF/jsp/inc/join_left_bottom_panel.jsp"/>
  <put-attribute name="rightTopPanel" value="/WEB-INF/jsp/login_form.jsp"/>
  <put-attribute name="rightBottomPanel" value="/WEB-INF/jsp/inc/find_form_panel.jsp"/>
</definition>

Видно, что в качестве основного шаблона используется файл /WEB-INF/jsp/layout/default.jsp:

<%@ taglib uri="http://tiles.apache.org/tags-tiles" prefix="tiles" %>
<%@ taglib prefix="s" uri="/struts-tags" %>
<html>
<head>
  <title><tiles:insertAttribute name="title"/></title>
</head>
<body>
  <div id="general">
    <div id="mainboard" class="mainpage">
      <tiles:insertAttribute name="leftTopPanel"/>
      <tiles:insertAttribute name="leftBottomPanel"/>
    </div>
    <div id="dashboard">
      <tiles:insertAttribute name="rightTopPanel"/>
      <tiles:insertAttribute name="rightBottomPanel"/>
    </div>
    <div id="footerbar">
      © <a href="http://www.magicwebsolutions.co.uk" target="_blank">
           Magicwebsolutions.co.uk</a>
      | <a href="/terms.action">Terms and Conditions</a>
      | <a href="/privacy.action">Privacy Policy</a>
      | <a href="/bugreports.action">Reports and Comments</a>
    </div>
  </div>
</body>
</html>

В нём содержатся:
1. Включения программных библиотек для обработки Struts-тэгов и Tiles.
2. Основная вёрстка (те фрагменты кода, которые не изменяются никогда, например, основные тэги и включения стилей и скриптов).
3. Struts-тэги для вызова серверных включений файлов или значений.

Третий пункт наиболее важен для рассмативаемой темы.
Синтаксис включения Tiles таков: <префикс:insertAttribute name="имя"/>. Префикс указан в самом начале файла в директиве <%@ taglib uri="http://tiles.apache.org/tags-tiles" prefix="tiles" %> — это значит, что в данном документе вид Tiles-вызовов будет таким: <tiles:insertAttribute name="имя"/>. В качестве имени указываются те имена атрибутов, которые использованы в файле tiles.xml. То есть если мы встречаем вызов <tiles:insertAttribute name="title"/>, то будет использовано значение, указанное в <put-attribute name="title" value="Значение"/> в определении того экшна, который актуален в данный момент.
Если описать это в виде процесса: запрашивается экшн, данные передаются серверу, в struts.xml описывается, что нужно сделать с данными (какой метод какого класса вызывается), экземпляр класса создаётся и заполняется данными, в случае успешного прохождения валидации (при необходимости) выполняется указанный метод, а в зависимости от того, что возвращается, используется тот или иной результат для данного экшна; в качестве результата, если его тип — tiles, — может быть указано имя для вызова Tiles; по этому имени из tiles.xml используется нужное определение (definition).
Внутри определений есть наборы тэгов <put-attribute name="имя" value="значение"/>, из которых и будет производиться выбор во время вызова <префикс:insertAttribute name="имя"/>. В зависимости от значения тэга <put-attribute name="имя" value="значение"/> и типа этого значения и будет производиться замена <префикс:insertAttribute name="имя"/> на конкретное содержимое внутри основного шаблона, который указан в Tiles-определении как шаблон по умолчанию: <definition name="defaultLayout" template="/WEB-INF/jsp/layout/default.jsp">, то есть файл /WEB-INF/jsp/layout/default.jsp.
С точки зрения вложенности шаблонов есть несколько файлов, иерархия которых определяется в tiles.xml, а конкретные случаи включений описываются с помощью struts.xml.
Но с помощью Tiles можно не только собирать страницы из файлов-фрагментов. Можно, например, заполнять вызовы простыми строковыми значениями. В тэгах <put-attribute name="имя" value="значение"/> можно указывать тип передаваемого значения: <put-attribute name="имя" value="значение" type="тип"/>. Типов четыре: string (строка), template (включаемый файл-шаблон), definition (вызов уже описанного определения) или object (объект). На самом деле тип указывать необязательно: Struts в большинстве случаев определяет тип корректно. В качестве строки можно указать обычное слово (как и происходит в случае с <put-attribute name="title" value="Login"/>), а если в начале значения стоит слэш (как в <put-attribute name="rightBottomPanel" value="/WEB-INF/jsp/inc/find_form_panel.jsp"/>), то Struts определяет тип данных как template и ищет ресурс по указанному пути, а если не находит, то выдаёт предупреждение. В нашем примере используются типы string и template.

Исходный код к уроку