Осенило!!! Используем новые возможности ViewData

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

Например если контроллер выполняет какую то работы и передает свои данные во View, то не используем типизированную ViewData. Используем стандартный словарь. Об этом я тоже писал.


И вот мы получили 3 релиз AspNet MVC. В котором немного поменялся вид этой самой ViewData. Теперь если вы используете типизированную ViewData, то для обращения к ней надо писать вот так ViewData.Model. А сама ViewData так и осталось словарем.
Тоесть если контроллер выполняет какие то действия, то результат можно запихивать в структуру и передавать как ViewData. Если же ViewData надо расширить какими-либо данные из вне, то их можно спокойно поместить во ViewData со своим ключем.

Я думаю такое изменение ViewData это попытка найти подход или решение, к передаче данных во View, не только из контроллера но и из sub-контроллера.

Переход на Trac 0.11, в отдельно взятой деревне.

У нас в команде для управления проектами и задачами используется trac. До не давнего времени(24,06,08) стояла 0.10 и в принципе всем устраивала, но вот встал вопрос о написании своих workflow для тикетов. Тем более что такая возможность была предоставлена в версии 0.11. Заодно решили пропатчить и остальной софт который нужен для работы trac-а
Зайдя на сайт и обновив знания об установки закачал следующий софт:
python-2.5
Genshi-0.5
mod_python-3.3.1
pysqlite-2.4.0
setuptools-0.6c7
svn-python-1.4.6
Trac-0.11

Питон 2.5 я решил оставить. А вот остальное заменить на более новые версии.
Новые версии софта помимо стандартной поставки(в виде исходников), стали предоставляться и в виде бинарников(запустил exe и сиди жди). Поэтому процесс установки занял мало времени и много сил не отнял. После установки новой версии надо обновить окружение проектов. Если раньше для работы с trac-admin надо было запускать его через python.exe, то в новой версии trac-admin поставляется как exe файл.
trac-admin C:\MyProjects\Project\ upgrade
На данном этапе проблем особых не было и все проекты спокойно обновили свое окружение.
Далее перезапустил Apache и зашел в управление проектом. Ввел логин и пароль... Тут и начались проблемы. Сервер принимал пароль с логином и вываливался по дисконнекту.
Логи апача показывали следующее:
[Tue Jun 24 15:05:15 2008] [notice] Parent: child process exited with status 0 -- Restarting.
[Tue Jun 24 15:05:15 2008] [notice] Apache/2.2.9 (Win32) DAV/2 mod_auth_sspi/1.0.4 SVN/1.4.5 configured -- resuming normal operations
[Tue Jun 24 15:05:15 2008] [notice] Server built: Jun 13 2008 04:04:59
[Tue Jun 24 15:05:15 2008] [notice] Parent: Created child process 4364
[Tue Jun 24 15:05:15 2008] [debug] mpm_winnt.c(487): Parent: Sent the scoreboard to the child
[Tue Jun 24 15:05:15 2008] [notice] mod_python: Creating 8 session mutexes based on 0 max processes and 250 max threads.
[Tue Jun 24 15:05:15 2008] [notice] Child 4364: Child process is running
[Tue Jun 24 15:05:15 2008] [info] Parent: Duplicating socket 280 and sending it to child process 4364
[Tue Jun 24 15:05:15 2008] [debug] mpm_winnt.c(408): Child 4364: Retrieved our scoreboard from the parent.
[Tue Jun 24 15:05:15 2008] [debug] mpm_winnt.c(605): Parent: Sent 1 listeners to child 4364
[Tue Jun 24 15:05:15 2008] [debug] mpm_winnt.c(564): Child 4364: retrieved 1 listeners from parent
[Tue Jun 24 15:05:15 2008] [notice] Child 4364: Acquired the start mutex.
[Tue Jun 24 15:05:15 2008] [notice] Child 4364: Starting 250 worker threads.
[Tue Jun 24 15:05:15 2008] [notice] Child 4364: Starting thread to listen on port 81.
Логи Windows 2003 выдавали, что произошла ошибка VsJITDebugger:
An unhandled win32 exception occurred in httpd.exe [8024]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on.
В начале пришлось повозиться для отключения дебагинга, чтобы увидеть нормальную ошибку. Для этого надо было слазить в реестр винда и удалить ветку HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AhDebug.
После этого стала видна сама ошибка и почему она возникает:
Ошибка приложения httpd.exe, версия 2.2.9.0, модуль libapr-1.dll, версия 1.3.0.0, адрес 0x000079fc.
Порывшись на форумах была найдена причина. Оказывается версия файла libapr-1.dll который используется в при работе Apache не совпадает с версией файла который установлен вместе с пакетом svn-python-1.4.6.
Делал попытки скопировать файл одной версии в папку bin Апача и в папку svn-python(находится по пути \\Python25\Lib\site-packages\libsvn\). Все в пустую, проклятая ошибка была живее всех живых...

Проблема решилось только после отказа от svn-python-1.4.6 и возврата на svn-python-1.4.5.

Дальше стоит вопрос о переходе на SVN-1.5. Вот теперь думаю, а нужен он такой геморой ? )))))