TurboGears 2 vs Django - qualche consiglio sulla scelta di sostituzione per TurboGears 1?

Question

Sono stato con TurboGears 1 per la prototipazione siti di piccole dimensioni per l'ultimo paio di anni e si sta facendo un po 'lungo nel dente. Qualche suggerimento su come rendere la chiamata tra l'aggiornamento a TurboGears 2 o il passaggio a qualcosa di simile a Django? Sono combattuto tra la familiarità della comunità TG che sono abbastanza reattivo e fare abbastanza buona documentazione vs comunità molto più grande Django. Sto abbastanza tentato dalle funzionalità incorporate CMS e il supporto di Google AppEngine.

Qualche consiglio?

Grazie

.M.

Answer 1

Ho esperienza sia con Django e TG1.1.

IMO, TurboGears punto di forza è la sua ORM: SQLAlchemy. Io preferisco TurboGears quando il lato del database delle cose non è banale.

ORM di Django è solo che non flessibile e potente.

Detto questo, preferisco Django. Se lo schema del database è una buona misura con ORM di Django vorrei andare con Django.

Nella mia esperienza, è semplicemente meno problemi da usare Django rispetto al TurboGears.

Answer 2

TG2 è costruito sulla base di Piloni che ha una abbastanza grande comunità. TG ancora più veloce rispetto al TG1 e comprende un motore di caching per-metodo (non solo le pagine web). Penso che sia più AJAX-friendly rispetto Django dal modo in cui le pagine possono essere facilmente pubblicati in HTML o JSON.

2011 update: dopo 3 anni di quadri gonfi Sono un utente felice di http://bottlepy.org/

Answer 3

Sono stato con Django da un anno e quando ho iniziato non avevo esperienza di Python o di Django e l'ho trovato molto intuitivo da usare.

Ho creato una serie di hobbista Google App Engine Apps utilizzando Django con l'ultima delle quali un CMS per il mio sito. Django ha fatto sì che io sono stato in grado di codificare molto più veloce e con molta meno bug.

Answer 4

Sono sicuro che ci si avete letto da un sacco di confronto tra TurboGears e Django sul web.

Ma per quanto riguarda la vostra tentazione sul CMS e GAE, posso davvero pensare devi andare modo Django. Controllare questi fuori, e decidere Yourself.

Django con GAE

Django per CMS

Answer 5

TG2 sembra molto complicato e confuso, anche per fare un po 'di semplice come una pagina di accesso con i messaggi di errore multimple Come prolungare la TurboGears 2.1 login funzionalità Credo che questo è a causa di intemperanze in modularità ...

Answer 6

Django ORM utilizza l'implementazione record attivo - vedrete questa implementazione nella maggior parte ORM. Fondamentalmente ciò che significa che ogni riga nel database è direttamente associato ad un oggetto nel codice e viceversa. framework ORM come il Django non richiederanno predefinire lo schema per utilizzare le proprietà nel codice. Basta usarli, come il framework può ‘capire’ la struttura, cercando in schema del database. Inoltre, si può solo salvare il record nel database, come è associata a una riga specifica nella tabella.

SQLAlchemy utilizza l'implementazione Data Mapper - Quando si utilizza questo tipo di implementazione, v'è una separazione tra la struttura del database e la struttura degli oggetti (non sono 1: 1 come nella realizzazione Active Record). Nella maggior parte dei casi, si dovrà utilizzare un altro strato di persistenza per mantenere interagire con il database (ad esempio, per salvare l'oggetto). Così non si può semplicemente chiamare il metodo save (), come si può quando si utilizza l'applicazione Active Record (che è una truffa), ma d'altra parte, è il codice non deve conoscere l'intera struttura relazionale nel database di funzionare , in quanto non v'è alcuna relazione diretta tra il codice e il database.

Quindi, quale di loro vince questa battaglia? Nessuna. Dipende da quello che si sta cercando di realizzare. E 'il mio credono che se l'applicazione è un soprattutto un CRUD (Create, Read, Update, Delete) applicazione che le regole dure e complesse da applicare sui rapporti tra le diverse entità di dati, è necessario utilizzare l'applicazione Active Record (Django). Essa vi permetterà di facilmente e rapidamente impostare un MVP per il vostro prodotto, senza alcun problema. Se si dispone di un sacco di “regole di business” e le restrizioni nelle applicazioni, potrebbe essere meglio con il modello di dati Mapper, in quanto non vi legare e ti costringono a pensare rigorosamente come attivo Record fa.

Answer 7

Ive ha ottenuto solo una domanda ... è l'applicazione che si sta sviluppando indirizzati verso il social networking   o la logica di business personalizzati?

Personalmente trovo Django è un bene per il social networking e piloni / TurboGears se davvero   vogliono la flessibilità e non ha confini ...

solo la mia 2c