Мой глубокий вам поклон и уважуха, за те силы и старания которые вы прикладываете дабы заставить ее (cms) выполнять то что вам нужно. 

Попался мне в руки проект в котором заказик (немец) упорно настаивал на реализации проекта на Typo3 ну чтож как говориться “Кто платит тот и музыку заказывает”, да и что греха таить самому давно хотелось попробовыть реализвоть проект на typo3, а тут и возмножность подвернулась.

На мое субъективное мнение система не просто сложна в изучении и реальном применение, а просто мего сложна.

Пример почему мегосложна: элементарное действие отобразить шаблон сделанный дизайнером не подключая никаких активных элементов - просто отображение шаблона, сразу же окунает вас в тУпо3 скрипт, который без бубна изучать просто невозможно - и этому способстует не очень простая в освоении документация typo script.

Самое первое и основное, что отталкивает от изучения и применения typo3 - это использование их typo script, причем использование практическе везде, где нужно и самое главное, где не нужно и можно запросто обойтись без него.

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

Но не все так плохо, есть много и хорошего. 

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

Но не сильно обольщаятесь, к примеру на первый взгляд простой модуль Новости, в тУпо3 хорошо потрепает вам нервы, своей изощреностью в настройке, и дальнейшем добавлении новостей на ваш сайт.

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

Очень помог в изучении русскоязыный портал по typo3 - typo3.biz, на котором можно найти массу переведенной документации, Огромное им за это Спасибо!

Ну и конечно же офф сайт - этой замечательной cms - typo3.org

Что из этого получилось:

Но лучше всего увидить и спеть самому: http://dt.in.th/src/lyricscroll/ , правда автор этой штуковины из Тайланда, но я не думаю, для “нашего” человека после пива это будет являться проблемой.

Роутинги как объекты класса

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

Роутинг 1.2 совместим с 1.1 и не требует никаких дополнительных изменений в routing.yml файле.

Если вы хотите прописать роуты напрямую в PHP, теперь нужно указывать объект sfRoute вторым аргументов для методов connect(), preprendRoute(), appendRoute(), и insertRouteBefore() :

$routing->connect('foo_bar', new sfRoute('/foo/:bar', array('module' => 'foo', 'action' => 'bar')));

Настройка роута

Конструктор класса sfRoute принимает последним аргументом массив опций, который позволяет легко настраивать роуты. В конфигурационном файле routing.yml , ключ options применяется для замены настроек по умолчанию:

article:
  url:     /article/:id-:slug
  options: { segment_separators: [/, ., -] }  

В опции segment_separators  указываются символы разделители для роута. В предыдущем примере как разделитель  испольются - (дефис), которые в нашем случае так же валиден как и два разделителя встроенных по умолчанию (/ и .). Таких образом допускаются ссылки вида /article/1-my_article_title с переменной id равной 1 и slug равной my_article_title.

Эта опция уже доступна в symfony 1.1, но только глобально для всех роутов. Таким образов добавив глобальный разделитель, вы можете нарушить работу роутингов определенных в сторонних плагинах.

Кроме этого доступно еще две новых опции:

• generate_shortest_url: генерация коротких URL, насколько это возможно 
• extra_parameters_as_query_string: генерация дополнительных параметров в виде запроса

Эти опции могут быть заданы глобально либо отдельно для каждого роута. По умолчанию обе опции равны false в factories.yml для того чтоб сохранить совместимость с предыдущими версиями symfony.

Пример того как использовать эти опции для настроки роутов:

articles:
  url:     /articles/:page
  param:   { module: article, action: list, page: 1 }
  options: { generate_shortest_url: true }  

Этот роут генерит максимально короткий URL. Т.е. если запросить page равное 1, что является значением по умолчанию для переменной page, на выходе получим URL вида /articles:

echo url_for('@articles?page=1'); // generates /articles
// would have been /articles/1 in symfony 1.1   

echo url_for('@articles?page=2'); // generates /articles/2  

Другой пример, как работает опция extra_parameters_as_query_string:

articles:
  url:     /articles
  options: { extra_parameters_as_query_string: true }  

Такой роут принимает дополнительные параметры, которые не валидны для переменных заданных в патерне роута (в самом примере таких переменных как мы видим вообще нет):

echo url_for('@articles?page=1'); // generates /articles?page=1
// would not have matched the route in symfony 1.1

echo url_for('@articles?page=2'); // generates /articles?page=2  

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

Настройка роутингов

Вся логика из класса sfPatternRouting была перемещенна в объект sfRoute:

• Когда пришел HTTP запрос, объект роутинга опрашивает каждый роут не совпадает ли он с зпрошеным URL.
• И в момент когда вы хотети сгенерировать URL, объект роутинга опрашивает каждый роут на возможность сгенерировать URL по предоставленным параметрам.

Добавление всей логики в класс роутига, в этом случае не важно либо это создание нового класса роутинга для иземения направления парсинга роутов либо генерация всего процесса роутов.

Если вы хотите изменить класс обработки роутов используемый по умолчанию на свой, добавьте ключ class в файл конфигурации роутов:

article:
  url:   /article/:id
  param: { module: article, action: index }
  class: myRoute  

С такой конифгурацией ротинга, для обработки роута article symfony будет использовать класс myRoute, вместо стандартного класса sfRoute. И теперь роуты будут зависить от поведенния заданного в вашем классе.

Новый класс sfRoute намного модульнее чем старый sfPatternRouting, что позволяет легко настраивать стандартное поведение класса.

Стандартный sfRequestRoute

В Symfony есть стандартный класс роутинга, sfRequestRoute, который можно применять в ходе процесса сопостовления HTTP метода:

article:
  url:          /article/:id
  requirements: { sf_method: get }
  class:        sfRequestRoute  

В представленной конфигурации роутинга, роут article будет совпадать только запросу с HTTP методом GET.

Если вы хотите задать несколько роутов с одинаковым url, но с разными методами, вы можете добавить параметер  sf_method во время генерации роута:

<?php echo link_to('Great article', '@article?id=1&sf_method=get')) ?>  

Теперь это стало возможно так как ротинг уже знает о запрашиваемом контектсе. Во время отправки запроса, роутинг полчается следующий контекст:

• method: HTTP метод
• format: формат запроса 
• host: имя хоста 
• is_secure: был ли запрос вызван через HTTPS или нет 
• request_uri: полный запрошеный URI  
• prefix: префикс добавляемый к каждому сгенерированному запросу

В общем sfRequestRoute - это первый шаг на пути к простой архитектруре.

Что дальше?

В следующей части, мы познакомимся с тем как symfony управляет рессурсами при автоматической генерации роутов основанных на простой конфигурации файла routing.yml.

О новой системе роутинга будет доклад на symfonyCamp с большим количеством примеров и живим демо, так что все желающие пока еще не поздно регистрируйтесь.

Если вы хотите следить за процессом внедрения изменений в symfony 1.2 проверяйте переодически страницу upgrade to symfony 1.2 все новинки будут появлятся на ней в по ходу появляния.

Все таки  Крым не сравнишь ни с Кавказаом, ни с Турцией или Египтом.

Крым - одна сплошная красотища!

Ласточкино гнездо (малееенькое)

Безумный подъем на Ай-Пертри (на высоты более 1200 м за 15 минут)

С самой высокой точки Ай-Петри фото станции фуникулера (подъемника), здание треугольником

Внизу Ялта, Мисхор

Осообенно трепетно к этому относятся заказчики за пределами СНГ

Валидатор от w3.org, конечно хорошо, но как всегда хочеться большего.

В нашем случае “большее” - это живой валидатор в реальном времени, автор живого валидатора (Validator.nu) Henri Sivonon взял Hixie’s Live DOM Viewer, и на его основе собрал свой парсер DOM.

Получилось я вам скажу очень даже неплохо.

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

Почему собственно PHP Simple HTML DOM Parser:

• Написан на PHP5+ и позволяет легко управлять HTML
• Поддерживает не валидный HTML
• Поиск тагов в HTML с селекторами в jQuery стиле
• Может разложить все содержимое HTML в строку

Скачать последнюю версию с Sourceforge.

Онлайн документация.

Небольшой пример, как извлеть HTML элемент:

// Create DOM from URL or file$html = file_get_html('http://www.google.com/');


// Find all images
foreach($html->find('img') as $element)
  echo $element->src . '<br>'; 

// Find all links
foreach($html->find('a') as $element)
  echo $element->href . '<br>';

• Появилось новое поле для описания плагина. Это поле не зависит от версии плагина и будет выводиться на главном табе “Plugin Information”.
• Каждый плагин можо связать с ORM, который он использует. Первоначально это свойство задавалось автоматически основываясь на имени плагина и некоторых “таинственных” характеристиках. Теперь это поле может задать разработчик. С этого момента информаци о используемом ORM в плагине станет более достоверной.
• Добавлен полезный инструмент для тестирования README файла перед созданием PEAR пакета. Для проверки заходим на страницу проверки валидности Markdown. На этой же странице вы найдете и шпаргалку по разметке Markdown.

• Еще у большого количества плагинов README файл написан в trac wiki синтаксисе. Для конвертации в новый формат Markdown, теперь можно загрузить конвертер в табе “README”.
• Система плагинов основывается на некоторых соглашениях по представлению информации о них, но эти соглашения нигде неописаны, поэтому добавили FAQ для разработчиков, который отвечает на большенство вопросов заданных по новой системе плагинов. Если у вас все еще есть вопросы пишите их Фабьену (мильник есть на офф сайте)
• При загрузки ваших PEAR пакетов, symfony проверить ваш пакет и вслучае неудачи выведет ошибки описывающие проблему с пакетом. Так же добавлен “строгий” режим, при включении которого, symfony так же проверить плагин и на стандартные соглашения по плагинам. Так к примеру в “строгом” режиме файлы LICENSE и README нужны для пакета обязательно. В будущем также будут добавлены новые режими проверки.
• Поисковый модуль пополнился новыми флагом “стабильность” плагина. И так же стал доступен на  отдельной странице. Поисковый движок теперь выдает GET запрос, что позволяет добавлять поисковые запросы в букмарки либо делать копи\паст нужным вам запросам.

На сегодня это все. Но кроме улучшений самой системы, желательно, чтоб все разработчики плагинов добавили “таги” к ним, и обновли package.xml файл. Так, что если ТЫ разработчик плагина(ов), потрать пару минут для обновления плагина и добавления к нему необходимой информации. И если вы еше не загрузили PEAR пакет вашего плагина, то сейчас самое время это сделать.

Ну и на последок, сейчас все еще нет хозяев у 45 плагинов, так что если вы один из владельцов пожалуйста напишите письмицо Фабьену и не забудьте указать имя вашего плагина и ваш логин в trac.

Ежегодная встреча сообщества symfony состоиться 12-13 сентября в Dutch Open Projects (DOP), что в Голландии.

Мероприятие начнется с тренинга по symfony 1.1, предствляет Nicolas Perriault (менеджер релиза symfony 1.1).

Докладов не так много, и на мой взгляд как-то маловато для такого мероприятия, вот список некоторых из них:

• Обучающие уроки от Yahoo! (Dustin Whittle)
• Производительность symfony (Fabian Lange) - это интересно
• symfony и Doctrine vs Propel (Jonathan Wage, главный разработчик Doctrine)
• Библиотеки интерфейса пользователя от Yahoo (Dustin Whittle)
• Плагины и как создавать свои собственные (Lambert Beekhuis)
• Генерация Админ панели (Ian Christian)
• symfony 2.0

Кто созрел, регистрируется, и потом рассказуется всем нам как там было хорошо ))

На офф сайте доступно 100 презентаций (все на английском языке), вот некоторые из них:

• Architecture of Maria, the New Transactional Storage Engine for MySQL
• Advanced wxPython Nuts and Bolts
• Cloud Computing with bigdata
• Code Reviews for Fun and Profit
• Even Faster Web Sites
• Hack This App! PHP Security Workshop
• How to be Normal: A Guide for Developers
• Integration Testing PHP Applications

Море интересных презентаций, просто глаза разбегаются

Но существующаю система работы с плагинами не может ответить на вопросы:

• А есть ли плагин который добавляет “вот такую штуку” ?
• А поддерживает ли мой любимый плагин новую версию symfony 1.1?
• А совместим ли плагин с Doctrine?
• А какие самые популярные плагины?
• Как я могу помочь доработать плагин?

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

Ну и вот теперь у нас есть совершенно новый раздел “Plugins” (в верхнем меню), который и дополнил старый добрый Trac.

Что умеет

Ниже список фич новой системы плагинов:

• Страница плагинов отображает все существующие на данный момент плагины, их можно отсортировать по версии symfony, по используемой ORM модели, по автору либо по имени плагина
• У каждого плагина, как и раньше, есть отдельная страница, с информацией о плагине, с текстом лицензии, с процессом установки, readme, зависимостями, списком релизов отсортированным по версиям symfony и админ панелью для разработчика плагина. Эту страницу так же можно настроить под каждую версию отдельно.
  
• Вся информация залинкована между собой, это означает что вы легко можете найти всех разработчиков плагина, либо все плагины выбранного разработчика
  
• Владелец плагина (его главный разработчик) получает доступ к админ панели управления плагином (редактирование описание, категорий, …), загрузке новых релизов и управлнию командой разработчиков плагина.
  
• Над каждым плагином могут работать несколько разработчиков с разными правами (ролями):
  - девелопер: имеет доступ к репозиторию плагина (если он расположен в  репозитории symfony)
  - сборщик: может загружать новые релизы и удалять старые
  - владелец (лидер): что хочет то и делает с плагином
• Теперь если вы хотите помогать в разработке существующего плагина, достаточно попросить доступ у Владельца плагина. Этот процесс очень прост, так как сейчас все автоматизировано, от создания акканута до авторизации в SVN
  
• Категории к которым относятся плагины, может выбирать владелец (главный разработчик) админ панели управления плагином. И когда большую часть плагинов растусуют по категориям, появится возможность на главной странице плагинов отсортировать их еще и по категориям.
• Все trac аккаунты были перенесены в новую систему, и сейчас вы можете залогинится с вашим существующим trac аккаунтом. Т.е. одинаковые аккануты сейчас используются для Trac, Плагинов, и Subversion.

Для разработчиков плагинов

Во время переноса в новую систему, произошли некоторые изменения. Ниже спискок главных моментов, которые нужно учитывать при разработке плагинов:

• Информация о плагине, отображаемая на странице плагинов, берется из файла package.xml. Поэтому все владельцы плагинов, должны проверить и исправить свои package файлы.
  
• Раздел “Лицензий” в админ панеле плагина, покажет файл ЛИЦЕНЗИИ PEAR пакета, если он есть. Если его нет, то пожалуйста добавьте его в корень вашего PEAR пакета с текстом самой лицензии.
  
• Раздел “readme” покажет файл README. Формат этого файла сменился с Trac wiki markup на Markdown, так как этот формат используется во всей документации symfony. Конвертация в Markdown из Trac wiki markup, происходит автоматически, но так как она оставляет желать лучшего, нужно сомстоятельно проверить файл README на соответствие Markdown синтаксису
  
• Скрипт импорта автоматически связал владельца плагина с его плагином, но это сработало если email в вашем trac аккаунте совпадал с email’ом, который вы указали с файле package.xml. На данный момент порядка 85 плагинов не имеют хозяев (налетаем и разбираем, кому плагинчик!). Если вы владелец плагина и вы не можете получить к нему доступ, отправьте письмо с именем вашего плагина и логином Фабьену (fabien.potencier[at]symfony-prokect.com)
  
• Некоторые плагины не были перенесены так как были с ошибками.
  Если вы не нашли своего плагина в новой системе, тогда посмотрите на странице плагинов с ошибками для того чтоб узнать причину. Если не знаете как побороть возникшую проблему, пишите Фабьену должен помочь
  
• Страница с плагинами в Trac перенаплавляется на новую страницу плагинов, так что пользователи попадут туда куда хотели.

В завершение

Новая система плагинов не заменяет текущую Trac систему, и так же не предлагает SVN репозитории для плагинов. Это потому что новая система не заменяет систему формирования проекта symfony. Разработчики все еще трудятся над такой системой, которая предоставит для наших плагинов выделеный SVN репозиторий, систему трекинга, wiki, и еще кучу всего разного… Так что оставайтесь на связи!