Fatica

[cstrap]

In generale ho l'impressione che con Python e i suoi framework web si debba faticare di più rispetto a Ruby e Rails

Dipende. Se confronti flask, hug, sanic... Direi che sono al pari, se non più versatili e leggeri per scrivere RESTful API

L'asso nella manica di Django è l'admin. Vero che non è adatto al più delle volte per svilupparci sopra la tua applicazione, ma per un rapido prototipo fai la tua sporca figura e in tempi brevi, scrivendo una manciata di codice.

ROR ha un'admin? Che potenzialità ha? Fa solo scaffold o di più?

[pmontrasio]

Sull'admin di Django concordo. Rails non ha un admin e bisogna usare gemme tipo http://activeadmin.info/ Nella pratica l'ho visto usare molto poco. Non so perché non ci sia un admin di default in Rails. Va detto che raramente serve e raramente l'ho usato anche in Django, se non per creare due utenti che avrei potuto creare da console (infatti in Rails lo faccio da rails c).

Se una delle ragioni per usare l'admin in Django è lo scaffolding dell'applicazione, allora ecco forse la ragione per cui Rails non ne ha uno grafico: Rails ha uno scaffolding command line molto pratico http://guides.rubyonrails.org/command_line.html#rails-generate Lo si usa per creare modelli, controller e viste consistenti tra di loro e dà un CRUD con cui iniziare. Tipicamente poi si aggiungono metodi ai modelli, si modifica un po' il controller e si butta la vista (il template Python) rimpiazzandola con il codice in arrivo dai designer.

Scavando nella memoria, tanti tanti anni fa avevo creato un'applicazione Rails per un cliente usando ActiveAdmin, ma poi appena il cliente chiede anche solo una piccola cosa in più si impazzisce nel cercar di piegare i default del sistema e viene voglia di rifare tutto in Rails "standard".

@cstrap Aggiungiamo una sezione con queste considerazioni? Forse servirebbe qualcosa che spieghi meglio cosa fa davvero l'admin di Django.

Di Web2py non ti so dire molto, l'unica ragione per cui ho usato la sua parte di amministrazione è consultare i messaggi di errore.

[cstrap]

L'admin non fa un mero scaffolding, ma mette a disposizione una serie di strumenti "magici", perché nell'admin di magia ce n'è molta. Lavoro su un sistema gestionale che si basa sull'admin e django-cms usa pesantemente parti dell'admin (ModelAdmin) per la gestione dei plugin. L'admin ha già pronto un sistema di ricerca con filtri e con poche righe di codice (import a parte ;-) ) si riesce a personalizzare parecchio, compresa la granularità di accesso con permessi e ruoli. Ancora, si possono suddividere i dati mostrati in serie, ad esempio anno, mese, giorno. È tanta roba. Non ricordo se c'è ancora una issue aperta, ma pensavano di estrarre l'admin in una django app. Come dicevo, l'admin non è la soluzione ai nostri problemi, ma copre molti use case. Di nuovo, grazie alla semplicità nel costruire form, model ecc, molti suggeriscono di partire senza admin e di utilizzarlo solamamente lato sviluppo, per aver un controllo backend sui dati e costruire l'applicazione senza legami ad una app di terze parti. A mio avviso, anche partendo con l'admin, si riesce a uscire agilmente dai binari (perdona, ma ci sta) aggiungendo man mano la complessità fino a staccarsi completamente. Chiaro che quest'ultima affermazione è parecchio forte, perché dipende molto da quanto guano è stato introdotto precendentemente.

[pmontrasio]

Ho fuso le nostre considerazioni in master 5e65486