Próbuję obalić Cappuccino. Chciałbym, żeby mój StackOverview sprawdził poniższą architekturę i zobaczył, czy ma to sens - celem jest wykorzystanie unikalnych zalet Django i Cappuccino bez podwajania się tam, gdzie technologie się pokrywają ...

Gdy przeglądarka internetowa żąda „przyjaznego” adresu URL (np. /, / Artykuły itp.):

Urls.py DJango dopasowuje to do widoku.Widok, a nie typowa praca DJangosa polegająca na wypełnianiu szablonu dyktatem miejscowym,
zwraca mały kod HTML „stub” używany bezpośrednio w aplikacji Cappuccino.Klient otrzymuje HTML CappuccinoKlient żąda adresów URL JS Objective wymienionych w kodzie HTMLAplikacja użytkownika końcowego jest wykonywana i wyświetlana w przeglądarce

Przeglądarka ma teraz działającą aplikację. Kiedy użytkownik robi coś, co wymaga czegoś od serwera:

Przeglądarka wysyła zapytanie XMLHTTPRequest do adresu URL.URLs.py Django dopasowuje to do widoku.Widok działa, może współdziałając z modelem DB. Ale zamiast zwracać szablon, Django zwraca trochę JSON.Klient otrzymuje JSON i robi wszystko, co musi zrobić.

Czy to ma sens? Nadal korzystamy z przyjaznych adresów URL, a tworzona baza danych umożliwia nam modelowanie naszego kodu. Jednak zamiast używać szablonów, udostępniamy strony pośrednie Cappuccino i odpowiedzi JSON, aby dać użytkownikom coś więcej jak prawdziwą aplikację i mniej jak silnik szablonowania HTML.

Czy może jest lepszy sposób na robienie rzeczy? Czego używają inne Pythonistas? Dziękuję za twój komentarz.