Visto che l’unica alternativa valida, per ora, a Python ed a un suo qualsiasi web framork, è Ruby on Rails, eccomi! Sto provando ruby on rails.

Per installarlo è una scocciatura abbastanza infinita. Fortunatamente sul mac c’è già tutto ed è sufficiente dare questi tre comandi:

sudo gem update --system
sudo gem install rails
sudo gem install sqlite3-ruby

Che aggiornato gem (il gestore pacchetti di ruby) ed installano rails ed sqlite, il database più migliore che c’è…

Gem fa schifo, veramente schifo, è lento non da alcun tipo di messaggio, ho pensato varie volte che si fosse piantato, invece no, è solo lento.
(more…)

Dopo neanche una settimana sono arrivato alla conclusione, affrettata, che pyramid non fa per me.
La possibilità di scegliere tra i vari moduli è una chimera poiché ogni modulo ha delle dipendenze strettissime e spesso incompatibili con altre.
L’esempio più eclatante è deform che non supporta jinja2 ma giusto chameleon e mako come motori di rendering.

Inoltre la documentazione è troppo frazionata e cercando su google non si trovano tutti sti grandi risultati, anzi…

Sicuramente, sarebbe bastato insistere qualche altro giorno ma io oramai ho sei giorni per finire un sito, che devo ancora iniziare.

Da oggi, si inizia con Ruby on Rails

I form sono la parte più vitale, importante e necessaria di un sito, al giorno d’oggi. E fanno schifo, almeno quanto i dns.

Attualmente pare che la miglior soluzione sia quella di utilizzare deform.

Va prima di tutto installato e attivato, l’installazione avviene facilmente con easy_install, per attivarlo basta aggiungere ad __init__.py

config.add_static_view('static', 'deform:static')

Ho creato un file chiamato schema.py con il seguente contenuto:

1. import colander
2.  
3. class Event(colander.MappingSchema):
4.     title = colander.SchemaNode(colander.String())
5.     slug = colander.SchemaNode(colander.String())
6.     abstract = colander.SchemaNode(colander.String())
7.     idb = colander.SchemaNode(colander.String())
8.     place = colander.SchemaNode(colander.String()) 
9.     datetime = colander.SchemaNode(colander.DateTime())
10.  
11. class Events(colander.SequenceSchema):
12.     event = Event()
13.  
14. class Schema(colander.MappingSchema):
15.     events = Events()
16.  
17. schema = Schema()

Il tutto dovrebbe servire per creare il form, grossomodo rispecchia punto a punto gli elementi dell’oggetto Event in models.py.
Dentro views.py ho creato una vista edit fatta così:

1. @view_config(route_name=‘edit’, renderer=‘templates/edit.jinja2′)
2. def edit(request):
3.     schema = Schema()
4.     dbsession = DBSession()
5.     myform = Form(schema, buttons=(‘submit’,))
6.     if ‘submit’ in request.POST:
7.         controls = request.POST.items()
8.         try:
9.             appstruct = myform.validate(controls)
10.         except ValidationFailure, e:
11.             return {‘form’:e.render(), ‘values’: False}
12.         # Process the valid form data, do some work
13.         values = {
14.             “name”: appstruct['name'],
15.             “shoe_size”: appstruct['shoe_size'],
16.         }
17.         return {“form”: myform.render(), “values”: values}
18.     # We are a GET not a POST
19.     return {“form”: myform.render(), “values”: None}

Ma poiché non c’è la MINIMA compatibilità con jinja2 devo ricambiare motore di rendering.
Pyramid mi inizia a stare pesantemente sul cazzo.

Il primo step è:
source env/bin/activate

Se il tutto ha funzionato la shell diventa qualcosa di simile a questo:
(env)pc:progetto user$
D’ora in avanti l’ambiente python utilizzato è quello del virtualenv e non c’è bisogno di eseguire i comandi con il path completo (es. $python invece di $../bin/python).

Fatto partire il server di develop con pserve:
pserve development.ini --reload
(more…)

AHAHAH! Si inizia!

Con django non mi sono trovato bene; strutturare un sito ad applicazioni non l’ho trovato agevole e integrare altre applicazioni è stato fallimentare. Infine l’interfaccia di amministrazione creata automaticamente si è rivelata una infinita perdita di tempo poiché non proprio semplice da personalizzare.

E quindi ora ci si riprova, dopo tre giorni (circa ) passati a scegliere, con un nuovo framework.

(more…)

elacava@table:/usr/lib/python2.7/dist-packages$ stat fhoilsiu
File: “fhoilsiu” -> “/home/fhoilsiu/src/fhoilsiu/”

Per adesso, l’unico modo rapido di utilizzare un modulo in sviluppo con python & debian.
Non esistendo PYTHONPATH…

Git, funziona.
(more…)

Per noia:

wiki.debian

ssh-keygen -t dsa

ssh $remote_user@$remote_host mkdir -p .ssh
cat .ssh/id_dsa.pub | ssh $remote_user@$remote_host ‘cat >> .ssh/authorized_keys’

Questo va fatto per ogni utente da usare con GIT

MODPYTHON DIMMERDA!!!!

Assicurarsi che sia installato

python-mysqldb
libapache2-mod-wsgi

Con adduser creare l’utente, poi con

usermod -a -G www-data utente

aggiungere l’utente al gruppo www-data, quello con cui viene eseguito apache, per non avere problemi di permessi.
Nella cartella site-available di apache2 creare il file di configurazione,

ServerAdmin webmaster@miramuseo.lan
ServerName www.miramuseo.lan
ServerAlias miramuseo.lan
DirectoryIndex index.html index.php
DocumentRoot /home/miramuseo/www

ErrorLog ${APACHE_LOG_DIR}/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog ${APACHE_LOG_DIR}/access.log combined
WSGIScriptAlias / /home/miramuseo/www/miramuseo/django.wsgi

Alias /static/ /home/miramuseo/www/miramuseo/static/

Order deny,allow
Allow from all

quindi attivarlo con

a2ensite miramuseo

Sed potrebbe essere utile nel copiare il file di un altro sito

sed -i ‘s/testo1/testo2/g’ file

.

A questo punto creare il file django.wsgi, come indicato nel file di configurazione qui su; il mio contiene:

import os
import sys

os.environ['DJANGO_SETTINGS_MODULE'] = ‘miramuseo.settings’

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

path = ‘/home/miramuseo/www’
if path not in sys.path:
sys.path.append(path)

Quindi, con git, copiare il progetto nella cartella www.

git clone ssh://elacava@mbp.local/Users/elacava/django_dev

Tutto molto semplice, url alla cartella in cui sta il repository git.

Se tutto è andato a buon fine, aprendo la pagina dovrebbero esserci una valanga di errori.
Il tutto si risolve con un semplice

python manage.py syncdb

Ovviamente, i parametri di configurazione di settings.py devono essere tutti corretti e il db deve essere precedentemente creato.

Se ci sono problemi di path, tipo errori ViewDoesNotExist at / aggiungere le varie cartelle nel path in django.settings

(more…)