Alessandro ha scritto:
Manlio Perillo wrote:
Se interessa, sto per publicare anche l'altro progetto per la gestione
dei forms:
http://developer.berlios.de/projects/nforms
A me interessa. Domanda: cosa ha in più rispetto a forms? (che comunque
non uso quasi mai, non riesco ad adattarmi ai css e a volte ho dei
problemi di implementazione delle pagine)
Probabilmente ti riferisci a formal.
Io mi sono scritto nforms perchè volevo che il layout dei forms si
decidesse via XHTML e non via codice.
Infatti lo scopo principale di nforms è quello di *adattarsi* ai forms
scritti in XHTML, offendo supporto per gestire lo stato del form e la
validazione dei dati.
Inoltre ho seguito il modello di xforms.
model = Model('aform')
model.bind('username', type=String(maxLength=10))
Input(model, 'username', label='username', help='insert your username').
Oltre ad Input ci sono Secret e Select1, il resto non è ancora implementato.
Oltre al modello e i controlli, ci sono i widgets che si occupano di
prelevare i valori immessi.
Di default il widget è scelto in base al tipo di dato (ad esempio per
DateTime il widget di default si aspetta, ad esempio:
date.year, date.month e date.day.
La versione corrente usa le data directive (che sono il male, per quanto
riguarda le performance).
Il prima possibile cercherò di farne a meno (e la cosa è facile dato che
la parte di integrazione con Nevow è ben separata dal resto, anzi,
volendo si può adattare anche a Django...).
La flessibilità è notevole, anche grazie ai pattern di stan.
A breve seguiranno la mia reimplementazione di guard e un package per la
gestione di un calendario (ispirato allo standard ical).
Ne abbiamo parlato un po' di tempo fa: io sono profondamente interessato.
Ho scritto qualcosa per la visualizzazione di un file calendario in
formato web; fa parte della riscrittura delle pagine di zope nella nuova
extranet twisted, che spero di completare da qui a tre mesi.
In questo mese devo mettere in produzione un engine di workflow, che ha
priorità sul resto; anzi, è meglio che mi metta a fare qualcosa...
La mia implementazione è solo il motore di un calendario.
Permette di definire Eventi, Todo e Journal (come previsto dallo
standard ical) e memorizzarli in un database.
Inoltre (ed è la cosa per cui l'ho scritto), gestisce gli allarmi,
sempre basandosi sul modello di ical.
Come logica comunque è molto semplice, una versione semplificata di ical.
Poi torno sul calendario e sul resto; sarei felice di darti una mano
-per scrivere test e documentazione o, nei limiti delle mie capacità,
per estendere tale package-.
Grazie.
Qua le esigenze di "calendari sempre accessibili" e "calendari
condivisi" si è fatta talmente forte che stavo valutando di tirare su
una seconda intranet dedicata a quello (egroupware, phpgroupware, ecc),
ma non ti immagini quanto io osteggi tale soluzione...
La mia implementazione non fa nulla del genere (magari si può estendere,
ma per ora non mi interessa e poi è complicato)!
Se non erro avevi detto che stai facendo qualcosa per l'amministrazione
degli utenti, o sbaglio?
Si, qualcosa di molto semplice; ho preso spunto da stiq di Valentino.
La gestione degli utenti si basa sui ruoli, ogni utente ha uno e un solo
ruolo.
Infine c'è l'integrazione con cred.
Andrà a finire che porterai twisted-nevow
avanti rispetto a django ;-)
Ma chi me lo sta facendo fare...
Comunque scrivere qualcosa come Django da zero è una impresa folle ;-).
Nemmeno mi interessa.
Io ho in produzione una gestione degli utenti e dei gruppi funzionante,
ma è scritta male e "concettualmente" da riscrivere, quindi non pubblico
niente :-(
Dai una occhiata a quello che ho fatto, quando sarà publicato, e fammi
sapere se ti va bene.
Saluti Manlio Perillo
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
