DcDr
Не согласен. Отдельный пост - отдельный ответ на отдельный вопрос.

Согласен ты или нет, не имеет значения. Обрати внимание на то, что ты один тут так пишешь.

DcDr
Точнее “разжеванного примера” там нет.

Его просто нет. Уточни для себя определение слова “пример”.

ZZZ

DcDr
Не согласен. Отдельный пост - отдельный ответ на отдельный вопрос.

Согласен ты или нет, не имеет значения. Обрати внимание на то, что ты один тут так пишешь.

Пишу на форуме вежливо, пишу удобно для других, аккуратно работая с цитированием.
А как все или не как все - дело десятое.
Скажем, на этом сайте многие работают “не как все” - фриленсеры, а не на постоянной работе. Наверняка, они неоднократно слышали от своих друзей-родственников “будь как все” ;)

DcDr
Точнее “разжеванного примера” там нет.

Его просто нет. Уточни для себя определение слова “пример”.

Я по примерам шаблонов из Pyramid разобрался. И начал использовать в реальном проекте.
Доскональным разжеванным примером то, что есть в шаблонах - конечно же не является.
Чтобы вникнуть в технологию, параллельно читая документацию, и начать работать - вполне достаточно.
Конечно, если бы пример был бы более полным, то лично я быстрее разобрался бы.
Но имеем то что имеем.

DcDr
Я по примерам шаблонов из Pyramid разобрался. И начал использовать в реальном проекте.
Доскональным разжеванным примером то, что есть в шаблонах - конечно же не является.
Чтобы вникнуть в технологию, параллельно читая документацию, и начать работать - вполне достаточно.
Конечно, если бы пример был бы более полным, то лично я быстрее разобрался бы.
Но имеем то что имеем.

Я не говорю, что нельзя разобраться. Всё можно. Можно и по исходникам изучать.
Но хороший удобный пример (как, например, с ZODB), позволяет начать разработку гораздо быстрее.

а можно еще пример на траверсинг, например такой (надеюсь он будет показательный и до меня “дойдет”):

делает разбор маршурта без связи с моделью проекта
например, если uri: /one, /two, /three - то вызивается вид test1.views.first
если uri другой - то вызывается вид: test1.views.second

ну и потом сам попробую совместить это с примером по локализации, и надеюсь выйду из тупика и перестану время терять :(

спасибо!!

Ну как бы траверсинг такого не делает. Просто по root (и прочих) должен возвращаться объект с типом, указанным в контексте вью.

brutka
а можно еще пример на траверсинг, например такой (надеюсь он будет показательный и до меня “дойдет”):

делает разбор маршурта без связи с моделью проекта
например, если uri: /one, /two, /three - то вызивается вид test1.views.first
если uri другой - то вызывается вид: test1.views.second

ну и потом сам попробую совместить это с примером по локализации, и надеюсь выйду из тупика и перестану время терять :(

спасибо!!

Фактически траверсинг есть вложенные друг в друга словари (или объекты имитирующие словари)
Каждый из этих объектов отвечает за свой подуровень uri.
Так понятно?

DcDr

brutka
а можно еще пример на траверсинг, например такой (надеюсь он будет показательный и до меня “дойдет”):

делает разбор маршурта без связи с моделью проекта
например, если uri: /one, /two, /three - то вызивается вид test1.views.first
если uri другой - то вызывается вид: test1.views.second

ну и потом сам попробую совместить это с примером по локализации, и надеюсь выйду из тупика и перестану время терять :(

спасибо!!

Фактически траверсинг есть вложенные друг в друга словари (или объекты имитирующие словари)
Каждый из этих объектов отвечает за свой подуровень uri.
Так понятно?

да. разобрался. получается понемногу. по крайней мере что такое контекст и что такое имя вида (и как это использовать при add_view) - понял.
остался только вопрос по примеру с локализатором.

не получается заставить работать “хитрый адаптер для поддержки локализации”
причина:
в случае коротких URI (/about, /en/about - где about - это имя вида (view_name)) - в уменя в контексте получаются разные объекты.

для случая - когда есть язык - и создается просто объект Root() (и который НА СЛЕДУЮЩЕМ шаге получается исключение KeyError) - получается в контексте Root.
А в случае когда языка нет, и возвращаем Root() - в контексте остается Localizer

brutka
не получается заставить работать “хитрый адаптер для поддержки локализации”
причина:
в случае коротких URI (/about, /en/about - где about - это имя вида (view_name)) - в уменя в контексте получаются разные объекты.

Имхо так:

1. Объект корневой, обрабатывающий /about у Вас есть…

2. Он же, этот же корневой объект, должен обрабатывать /ru, /en и возвращать сам себя для отработки /ru/about, /en/about, предварительно выставив флажок, что выбран язык X…

3. Этот же объект, обрабатывая /about без предварительно выбранного языка должен автоматически выставлять флажок языка (по умолчанию, по IP клиента или еще как то)

ну кто нить разобрался с traversal?
я так и не могу понять как должна работать root_factory?
все примеры показаны с одним классом, который обращается к бд, а если используется несколько классов, как тогда должна выглядеть root_factory?
какой формат возврата root_factory?
спасибо.

вроде бы в этой теме и так все разжевали…
еще можно здесь почитать http://faq1c.gorbunov.ru/node/85