За нещастие и аз вече не помня. Но сега ще ти изброя няколко изисквания:

• Трябва да подържаш няколко вида бази данни зад някаква абстракция. Дори ако се чувстваш смел - цял ORM. Да не се налага да се пренаписват моделите, когато сменя от sqlite на mysql.

• Template системите трябва да могат да са различни. ТвояТемплейтЕнджин, HAML, Jinja. ОК е да имаш нещо по подразбиране, а избора да някаква конфигурация.

• Трябва да имаш възможност за различни view-та за един и същи ресурс, в зависимост от поискания Content-Type. Тоест да уважаваш Accept хедъра на рикуеста ако този, който използва фреймуърка е направил съответните view-та.

• Контролерите ти трябва да различават HEAD, GET, POST, PUT, DELETE методите. Така програмита, използващ фреймърка ти да може да напише различен код за GET и DELETE за един и същи ресурс.

Got it!

Дойчо не помни, но го е измислил на наново. Днес ми дойде факса, за разговора ни. Исках от теб това:

Трябва да имаш възможност за различни view-та за един и същи ресурс, в зависимост от поискания Content-Type. Тоест да уважаваш Accept хедъра на рикуеста ако този, който използва фреймуърка е направил съответните view-та.

Конкретно моята идея беше всяко view (ако спазваме конвенцията приета в Python света, която иначе е по-известна като controller) да връща речник от скаларни данни (т.е. нещо, което може да бъде форматирано като JSON и XML), но да може да му бъде указван html template с декоратор, който да бъде използван, само ако клиентът си е поискал [x]html. Очевидно, в този случай резултатът от view-то ще бъде подаван като context на темплейта.

Не държа на това темплейтът да бъде указван с декоратор. Просто аз бих тръгнал по този път първоначално.