Document Actions
Intranet con Plone
Up to Plone Forum
Posted by
Ciao a tutti,
sto valutando sempre più l'uso di plone come gestore della intranet aziendale, ma mi sono oscure alcune particolarità che attualmento gestisco con altri sistemi.
Ora ho un applicativo PHP + Mysql su piattaforma LAMP con cui gestisco tutto il flusso informativo dell'azienda, quindi ticket assistenza tecnica, ordini verso i fornitori, ddt, diversi tipi di fatture, prodotti, anagrafica etc...
Tutti i dati sono salvati nel DB Mysql e li uso tramite PHP.
Quello che mi spaventa nel passare ad una soluzione Plone è il database ad oggetti interno di Plone, se dovessi avere un problema con l'interfaccia non sarei più in grado di risalire ai dati salvati nel db, cosa che ora potrei fare con mysqlquery_browser ad esempio.
Ho visto che Plone ha dei prodotti aggiuntivi per l'interfacciamento con i db esterni ma questo mi limiterebbe, credo, nelle prestazioni della intranet o comunque mi porterebbe ad avere sempre due sistemi da dover amministrare, mantenere e salvaguardare.
Qualcuno ha avuto esperienze simili con Plone gestendo l'intera struttura aziendale con una intranet Plone?
Le mie paure sono fondate o è solo la mia ignoranza su Plone che mi porta a fare queste valutazioni?
Grazie a tutti.
Ciao
Io volevo iniziare ad usarlo ma non sono nemmeno riuscito ad istallare l'add-on per la gestione ticket...
cmq ci dovrebbero essere delle funzionalità di back-up dei dati in plone!
il DB a oggetti di Zope è basato su una tecnologia stabile e piuttosto matura (si tratta di un DB capace di rispettare le proprietà ACID che solitamente trovi nei DB relazionali), del tutto equiparabile a quella dei DB relazionali a cui sei abituato.
se lo storage dei dati non risulta corrotto per qualche motivo, i dati saranno comunque accessibili, anche se per qualche motivo non dovessero esserlo direttamente da plone, perchè salta qualche logica applicativa.
quindi semmai il problema è valutare quanto lo storage ZODB adottato risulta robusto: una ricerca su google dovrebbe convincerti che non esistono grossi problemi, e anche se inciampassi in qualcosa di problematico, i backup sono fatti appositamente per quel motivo!
piuttosto, dato il tipo di applicazioni che vorrai costruirci sopra, semmai le considerazioni sul fatto di usare o meno un DB relazionale come backend dati vanno operate in termini di specifiche applicative: un DB a oggetti come lo ZODB non puo' coprire tutte le casistiche di cui potresti avere bisogno, e la scelta va ponderata di volta in volta.
Previously Maurizio Delmonte wrote:
piuttosto, dato il tipo di applicazioni che vorrai costruirci sopra, semmai le considerazioni sul fatto di usare o meno un DB relazionale come backend dati vanno operate in termini di specifiche applicative: un DB a oggetti come lo ZODB non puo' coprire tutte le casistiche di cui potresti avere bisogno, e la scelta va ponderata di volta in volta.
Cosa intendi con questo, io non sono assolutamente un esperto di DB ad oggeti e vorrei capire meglio se proprio queste problematiche mi segnali.
Attualmente il DB relazionale che uso lo sfrutto semplicemente con le varie chiavi primarie interne ed esterne più qualche vista che mi sono trovato già creata dallo sviluppatore precedente.
In cosa potrei essere limitato con lo ZODB?
Il timore (peraltro ingiustificato) dietro l'uso dello ZODB per mantenere dati importanti è piuttosto comune.
Perciò non preoccupatevi siete in buona compagnia.
Giustamente Maurizio ha portato la discussione sulle varie strategie di gestione dei dati di una intranet, soprattutto dei file e lui è decisamente esperto in quel settore perciò non aggiungo altro.
Porto però un'esperienza che spesso si è rilevata fondamentale per poter far dormire sonni tranquilli ai tecnici che ancora non erano molto familiari con Zope/Plone e cioè la possibilità di generare un export dai dati della Intranet in un formato facilmente leggibile.
Cioè con cadenza regolare, per esempio ogni notte, non solo si fa il backup, ma si fa anche un export (ovviamente incrementale) dei contenuti in formato XML o SQL in modo che se mai cadesse il mondo (NON È MAI SERVITO) si costruisce in fretta un'altra interfaccia con qualunque tecnologia.
Comunque posso riportartvi l'esperienza di più di 5 anni di Intranet e mai il problema è stata la perdita di dati.
Previously Fabrizio Reale wrote:
Il timore (peraltro ingiustificato) dietro l'uso dello ZODB per mantenere dati importanti è piuttosto comune.
Perciò non preoccupatevi siete in buona compagnia.
Meno male
Giustamente Maurizio ha portato la discussione sulle varie strategie di gestione dei dati di una intranet, soprattutto dei file e lui è decisamente esperto in quel settore perciò non aggiungo altro.
Per file intendi l'upload di un documento (PDF, CSV, fogli di testo e calcolo) in Plone che verra così poi indicizzato e reso disponibile per le ricerche o i dati interni allo ZODB che andranno poi a costituire un documento PDF?
Cioè con cadenza regolare, per esempio ogni notte, non solo si fa il backup, ma si fa anche un export (ovviamente incrementale) dei contenuti in formato XML o SQL in modo che se mai cadesse il mondo (NON È MAI SERVITO) si costruisce in fretta un'altra interfaccia con qualunque tecnologia.
Ecco cosa mi serviva sentire, poter in qualche modo abbandonare in caso di necessità l'architettura Zope/Plone mantenendo inalterati i dati del DB, ricostruendo al volo un'interfaccia temporanea.
Quello che ancora non riesco a trovare è un punto di partenza da cui provare a costruire un piccolo esempio di Intranet simile a quella che ho descritto precedentemente. Ho cominciato a leggere lo Zope book ma dopo un po mi sono accorto che tutto quello che faccio lì non è dentro Plone, quindi credo che dovrei concentrarmi su Plone ma non trovo nulla o forse mi sbaglio e Zope è il punto di partenza.
di fatto una delle sue peculiarità e' il DB a oggetti, che semplicemente va studiato a fondo, e va capito come Zope lo usa per la pubblicazione degli oggetti immagazzinati, per poi dimenticarselo!
se esiste lo ZODB è proprio per evitare di doversi preoccupare di immagazzinare i dati da qualche parte: buona parte dello sviluppo avviene senza preoccuparsi troppo di tabelle, indici, etc. etc.
quello che non riesco a fare e' fartelo capire con poche righe..
con poche righe pero' posso assicurarti da anni e anni di esperienza diretta e indiretta che la tencologia ZODB è solida come e piu' di quella dei DB relazionali, solo diversa.. profondamente diversa.
dai una bella lettura a questi articoli:
http://docs.zope.org/zope2/articles/
e a questo documento:
http://pypi.python.org/pypi/ZODB3/
o, in alternativa, fidati di quel che Archetypes fa per te quando costruisci i tuoi content types plone, e preoccupati solo di avere un backup, come faresti per qualsiasi altra applicazione
Previously Maurizio Delmonte wrote:
dai una bella lettura a questi articoli:
http://docs.zope.org/zope2/articles/
e a questo documento:
http://pypi.python.org/pypi/ZODB3/
o, in alternativa, fidati di quel che Archetypes fa per te quando costruisci i tuoi content types plone, e preoccupati solo di avere un backup, come faresti per qualsiasi altra applicazione
Ciao Maurizio,
ho letto i due documenti che mi hai postato e ho capito un po di più su ZODB, in pratica è come usare i dizionari e le liste in python se non ho capito male.
Ecco perchè Plone ci permette di spostare i contenuti da una parte all'altra del portale mantenendo sempre l'ID corretto e tutti i link a quel contenuto.
Grazie mille continuo a studiare Plone/Zope per cercare di capire come scrivere la mia prima mini-applicazione in Plone.
