immagina un manager che gestisce persone in sedi distaccate… potrebbe
volerle organizzare in gruppi che dipendono da lui… e che magari hanno
dei sottogruppi
poi magari lo stesso manager ha il suo segretario personale che lavora
per lui, quindi è relazionato solo a lui…
e lui stesso magari è parte del gruppo managers
a livello di model una soluzione a questo comportamento và pensata bene,
sopratutto per problemi di performance dovuti alla
ricorsività.
non mi sento di dare soluzioni ora, magari dopo qualche caffè :)
Solo una mia riflessione: è forse utile cercare di decidere che “scope”
deve avere ‘sto sistema di gestione utenti/gruppi. Sono problemi
piuttosto complessi (no, informaticamente parlando non sono problemi
complicati; è solo che sembra difficilissimo farlo bene!) questi e
forse vale un po’ lo stesso argomento che DHH usa per Rails stesso: è
solo tempo sprecato cercare di essere tutto per tutti. Rifai Java.
In un contesto aziendale esiste già un qualche sistema di gestione di
utenti/gruppi e fa quasi sempre schifo al maiale ma rimane lì perché …
… … boh, perché deve rimanere lì. Un meccanismo duttile e di facile
utilizzo per interfacciarsi con questi sistemi sarebbe La Vera Svolta.
Vi immaginate poter usare un documento YAML sul portatile di sviluppo,
un DB MySQL sul server di test e un mega LDAP in produzione? Sarebbe una
figata.
Se il backend fosse modulare ed astratto rispetto alle funzionalità di
base (crea utente/gruppo, cambia pwd, aggiungi metadati, gestisci
gerarchie tra utenti/gruppi, ecc ecc) sarebbe tempo guadagnato per
tutti…
David
Giuliano U. wrote:
Chiama i tuoi amici GRATUITAMENTE con la funzionalità di chiamata da PC a PC
http://get.live.com/messenger/overview_______________________________________________
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
“Remember, always be yourself. Unless you suck.” - Joss Whedon
Ah, poche ore e abbiamo già due scuole di pensiero
io l’avevo pensato in termini di rete più che di organigramma… perchè sono
interessato più a gruppi che si organizzano mettendosi d’accordo che non a
organigrammi calati dall’alto. chiaro, se il sw è per un’azienda devi
adeguarti al secondo modello, ma per ora preferivo concentrarmi sul
primo,
dove gli utenti all’interno di un gruppo hanno relazioni più paritarie… e
se vogliono qualcosa di più private… formano un altro gruppo.
quindi questo è il mio scope dichiarato.
avendo un’infrastruttura verticale di questo tipo, sarebbe possibile
anche
metterla a disposizione di vari app developer tramite una API. con le
info
utenti+gruppi concentrate su un unico server. che ne pensate?
On 8/31/06, david [email protected] wrote:
utilizzo per interfacciarsi con questi sistemi sarebbe La Vera Svolta.
a livello di model una soluzione a questo comportamento và pensata bene,
o un utente che> appartiene ad un utente… non è possibile pensare di
gli scherzi, in ambito aziendale è necessaria una struttura del> > genere,
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Chiaroscuro
Liquid Development: http://liquiddevelopment.blogspot.com/
Il 31/08/06, david[email protected] ha scritto:
[…]
forse vale un po’ lo stesso argomento che DHH usa per Rails stesso: è
solo tempo sprecato cercare di essere tutto per tutti. Rifai Java.
[…]
Vi immaginate poter usare un documento YAML sul portatile di sviluppo,
un DB MySQL sul server di test e un mega LDAP in produzione? Sarebbe una
figata.
allora avresti rifatto Java + JAAS
–
Michele F.
SeeSaw | Another point of view