ЗАЧЕМ НУЖНА СТРУКТУРИЗАЦИЯ
Создавая большие порталы, вы облегчаете поиск по файлам как себе, так и другим участникам-разработчикам портала, посчитайте время которое вы тратите в день на поиск и открытие файлов - примерно 10-20 сек (при не структурном хранение файлов), за 1 сессию работы с файлом (10-20 мин), и того выходит 1- 2 мин в час, 10-20 мин в день и того вы тратите на глупый поиск в месяц порядка 6-14 часов ! Это целый рабочий день. Для средней ЗП разработчика потеря составит 2400р. Вам это надо ? Так же, надо учитывать, что в разработку портала могут быть включены доп. ресурсы в виде программистов, верстальщиков и т.д. На повторное изучение среды разработки и структуры портала уходит время как ваше, так и человека, которого вы добавили в проект, порой включение нового человека обходится 1-2 часов в день, в течение месяца, здесь уже не 100 убитых енотов, а во много раз больше. Так что, делая структуру портала более «правильной», чистой понятной вы экономите свои же средства.
СТРУКТУРЫ В TYPO3
Это наверное самый важный аргумент в пользу TYPO, так как сайт на typo в общем то говоря и есть структура.
TS-уровень
Форматирование текста
Старайтесь меньше использовать конструкции вида
http://typo3.org/documentation/docum.../11/#id4090185
Пример плохого форматирования:
Код:
lib.leftmenu.20 = HMENU
lib.leftmenu.20.special = userfunction
lib.leftmenu.20.special.userFunc = user_3dsplm_pi2->makeMenuArray
lib.leftmenu.20.1 = GMENU
lib.leftmenu.20.1.NO {
wrap = <tr><td>|</td></tr><tr><td height="1"></td></tr>
XY = 163,19
backColor = white
10 = TEXT
10.text.field = title
10.text.case = upper
10.fontColor = red
10.fontFile = fileadmin/fonts/ARIALNB.TTF
10.niceText = 1
10.offset = 14,12
10.fontSize = 10
}
Лучше:
Код:
lib.leftmenu{
20 = HMENU
20{
special = userfunction
special.userFunc = user_3dsplm_pi2->makeMenuArray <- здесь я использую точку потому что внутри special не будет больше элементов
1 = GMENU
1{
ACT …
CUR …
NO{
wrap = <tr><td>|</td></tr><tr><td height="1"></td></tr>
XY = 163,19
backColor = white
10 = TEXT
10{
text{
field = title
case = upper
}
fontColor = red
fontFile = fileadmin/fonts/ARIALNB.TTF
niceText = 1
offset = 14,12
fontSize = 10
}
}
}
}
}
Читаемость второго варианта увеличивается на порядки.
Структурирование
Храните все ваши настройки внутри lib.
Заведите свою директорию, так чтобы ее название не пересекалось ни с чем в этом мире, я использую
.nksh. либо
.prme., тем самым получится, что все ваши персональные настройки будут храниться в
lib.[ваш дир.]..
Двигайтесь от общего к частному, например если вы запрограммировали расширение, где порядка 10-20 отдельных настроек помещайте их в соответствующую директорию к которым она относится например:
lib.prme.blog – основная директория в которой будут храниться настройки для блога.
lib.prme.blog.config – здесь конфигурацию, при этом объявляйте ее раньше остальных элементов, чтоб была возможность копирования директорий
lib.prme.blog.views – здесь мы будем хранить модули вывода, например (вывод одной записи, листа, облако тегов, самые крутые комментаторы и т.д.)
lib.prme.blog.forms – а здесь только формы ввода данных
TS-наследование
Сначала опишите основные черты вашего объекта (набора конфигурации), а дальше только уточняйте.
Например у вас есть 3 таблицы с 3 колонками, только в одной берутся данные из таблицы пользователей, в другой из таблицы группы пользователей, в третьей тоже из таблицы пользователей, но с другим набором полей как это будет выглядеть:
Код:
lib.prme.blog.config.my_table_1 = CONTENT
lib.prme.blog.config.my_table_1{
table = …
select{
…
}
renderObj = COA
renderObj{
10 = TEXT
10.field = …
20 = TEXT
20.field = …
30 = TEXT
30.field = …
}
}
lib.prme.blog.views.my_view_1 < lib.prme.blog.config.my_table_1
lib.prme.blog.views.my_view_1{
table = fe_users
renderObj{
10.field = uid
20.field = username
30.field = rating
}
}
lib.prme.blog.views.my_view_2 < lib.prme.blog.config.my_table_1
lib.prme.blog.views.my_view_2{
table = fe_groups
renderObj{
10.field = uid
20.field = groupname
30.field = num
}
}
lib.prme.blog.views.my_view_3 < lib.prme.blog.views.my_view_1 lib.prme.blog.views.my_view_3{
renderObj{
30 >
30 = IMAGE
30{
… send mail image config
}
}
}
Что у нас вышло:
Мы создали конфиг (
lib.prme.blog.config.my_table_1), который описывает общие черты таблицы.
lib.prme.blog.views.my_view_1 унаследовала
lib.prme.blog.config.my_table_1
lib.prme.blog.views.my_view_2 унаследовала
lib.prme.blog.config.my_table_1
lib.prme.blog.views.my_view_3 унаследовала
lib.prme.blog.views.my_view_1
Хранение файлов
Все пользовательские файлы хранятся в папке
fileadmin/, если вы используйте
TV, либо не используете, все равно храните ваши файлы внутри
fileadmin/templates/, дальше можете поступать как вам удобней, главное логически отделяйте файлы и папки, как делаю я:
Код:
fileadmin
-templates
-tpl – для общих шаблонов,
-i – картинок к шаблону,
-ts – общих TS-файлов,
-ttf – шрифтов,
-user_func – общих пользовательских ф-ий
-ext
-[myExtName] – Сюда можно помещать ваши расширения,
порой хранить расширения в typo3conf/ext/ не удобно, особенно в
период разработки, сохраняйте структуру файлов похожую, как в
родительском узле (шаблоны в tpl, картинки в i, и т.д.).
-[3rdPartyExt] – Файлы модифицированных расширений
можно помещать сюда пример:
-tt_news
-tpl
-anotherOne.tpl.html – модифицированный шаблон для tt_news
Наименование и объем файлов
Старайтесь, чтобы размер одного файла не превышал 300-400 строк, иначе в нем становится тяжело ориентироваться. Для одного файла хватит 1-3 контейнеров конфигурации. Названия файлов лучше использовать такими, как и путь в вашем TS-конфиге, например:
Код:
== TS ==
lib.prme.blog.views.my_view_1
лучше хранить в
Код:
fileadmin/templates/ext/blog/ts/views.my_view_1.ts
Тем самым, вы с легкостью сможете его найти, зная его путь в TS, либо зная название файла.
Большое спасибо за внимания, с уважением, Никитин Сергей.
PS. Дополнения и ошибки пишите, буду очень признателен.