Решение на Изберете си проект от Христо Владев

Обратно към всички решения

Към профила на Христо Владев

Код

# MVC framework, ползвайки WSGI и може би някакъв template engine.
# Като функционалност ще черпя идеи от Rails и ще имплементирам основните
# неща плюс каквото още успея.
#
# ПП: Аз бях обсъдил идеята с вас и имахте и конкретно изискване, но го
# забравих и ще трябва да ми го припомните.

История (1 версия и 3 коментара)

Христо обнови решението на 26.04.2015 23:31 (преди над 4 години)

+# MVC framework, ползвайки WSGI и може би някакъв template engine.
+# Като функционалност ще черпя идеи от Rails и ще имплементирам основните
+# неща плюс каквото още успея.
+#
+# ПП: Аз бях обсъдил идеята с вас и имахте и конкретно изискване, но го
+# забравих и ще трябва да ми го припомните.

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

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

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

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

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

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

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

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

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