Python-сообщество

Че вы докопались.
ИМХО каждый программист должен написать фремфорк. Это такой этап в жизни. =)
И он весьма полезен для развития и понимания как все работает.
Главное не задержаться в этом состоянии надолго.

lorien, я открыл тему не для обсуждения собственно моего фреймвёрка. Показывать код не собиралься (пока) ни для “смеха”, ни для еще чего - продукт сырой. Смысл видел в получении реплик по самому факту такого подхода, и получил их, и надеюсь получить еще. В ветке “web” настоящего форума кроме уже признанных решений никто никуда не суется и не делает “велосипед”. Видел книжку по джанго - она толще книг по пайтону - стало страшно - решил попробовать свое. Разумеется, дело не в толщине книги. Прочитав пару строк про фрэмвёрк jQuery (JavaScript), сразу возникло желание попробовать. Попробовал совсем чуть-чуть и ясно - это то что надо. С пайтоном так не получилось, к сожалению. Для постройки сайтов у меня написано несколько необходимых модулей для работы с переменными формы, работа с сессиями, контроллер унифицированный и под мод-пайтон для апача и под CGI…и все…и этого пока достаточно. Фреэмвёрком можно и не называть, но другого названия не придумал.
Тут спрашивали про мотивацию - надеюсь ответил. Мне самому интересна мотивация - почему обязательно фремверк? В ветке Django, люди задают вопросы и много вопросов. Впечатление такое, что они хотят приспособить монстра для своих не сложных задач.

Отредактировано (Авг. 11, 2010 18:54:15)

pioner
lВ ветке Django, люди задают вопросы и много вопросов. Впечатление такое, что они хотят приспособить монстра для своих не сложных задач.

Впечатление обманчиво. Смотреть надо глубже, ширше и пристальнее. “Делай настолько просто, насколько это возможно, но не проще.”

Блин, вот это наехали на человека.
Конструктивных замечаний 0. Человек сделал работу, попросил оценить. Отобьете всю охоту. Зачем это делать?

Мои советы и впечатления:
1. Взгляните на SkeletonZ. У вас идея look&feel админки очень схожа с этой. CMS хоть и дохлая, но код открытый, думаю, можно что-нибудь готовое выпилить оттуда.
2. На первый взгляд интуитивность работы с админкой желает лучшего.
3. Хотелось бы посмотреть в код. По-моему весь этот проект лучше повернуть в сторону CMS нежели фреймворка.
4. То, что под mod_python, это плачевно, ну, то есть, уже не современно. Пора переходить на mod_wsgi.

regall, спасибо.
1. “У вас идея look&feel админки” - такая админка есть в gallery (php) -
2. “интуитивность работы с админкой желает лучшего” - да, согласен. что подскажете?
3. “повернуть в сторону CMS” - читаете мысли.
4. “Пора переходить на mod_wsgi.” - на доступных мне хостах пайтон версии 2.3 (рабочий) и 2.4 (для теста), mod_wsgi доступен c версии 2.5.

p.s. Охоту форум не может отобить в принципе. Она пропадает по другим причинам :)

pioner
2. “интуитивность работы с админкой желает лучшего” - да, согласен. что подскажете?

Я, конечно, не юзабилист (дурацкое слово), но первое, что кидается в голову:

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

Ну, как-то так. Пока это все, что приходит на ум.

Про юзабили в ветке web почти нет тем, а зря.

regall , большое спасибо за комментарии.
1. Расположениекнопок ссылок - за основу редактора контента взят сторонний rtejquery, который автор перестал поддерживать. Я кое-что исправил, добавил свои кнопки-ссылки, графические иконки оставил авторские. Видимо, лучше все свести к одному стилю.

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

3. Там и так все через ajax (почти), но думаю что способ общения с сервером больше завязан на его конструкцию - удобство использования уже написанного функционала, а для пользователя как обновилась страница, думается, не очень существенно, если не принимать в расчет скорость сети и величину трафика.