Titolo della pagina: T2 CMS ROME (T2_IT_ROME) DASHBOARD
Quasistatic e struttura directory corrente up. Farm down.
Rack monitoring: intercettare il segnale di allarme e far comparire una barra rossa (css). scriptino php statico sulla pagina principale, niente reverse engineering.
lunedì 14 gennaio 2008
giovedì 10 gennaio 2008
installazione
il primo panel phedex è up & running, con cron e tutto. Non ancora ajaxificato, ma finché non torniamo commissioned non c'è fretta.
Da Installare XML::Writer per staticInfo. Fatto grazie.
XML wasn't designed to be edited by humans on a regular basis. - Guido van Rossum
Però io voglio php5 e simplexml...è doloroso istanziare un parser solo per pescare UNA tag (lastUpdated). Ma è l'unico modo per disaccoppiare (credo).
Da Installare XML::Writer per staticInfo. Fatto grazie.
XML wasn't designed to be edited by humans on a regular basis. - Guido van Rossum
Però io voglio php5 e simplexml...è doloroso istanziare un parser solo per pescare UNA tag (lastUpdated). Ma è l'unico modo per disaccoppiare (credo).
sabato 5 gennaio 2008
fancystuff
Essendo il fine settimana dedicato agli incontri familiari ho fatto cosine semplici e di divertimento nei ritagli di tempo. Cosa sto sperimentando:
-far parlare php e javascript (idea: far echo con php di codice javascript, con variabili riutilizzabili negli script successivi)
-classe Container YUI: draggable panel. Come la pagina di google, bisogna capire come ancorare a tag posizionate attraverso css perché i float diretti del container non funzionano benissimo)
TODO: come salvare una configurazione del genere?
-far parlare php e javascript (idea: far echo con php di codice javascript, con variabili riutilizzabili negli script successivi)
-classe Container YUI: draggable panel. Come la pagina di google, bisogna capire come ancorare a tag posizionate attraverso css perché i float diretti del container non funzionano benissimo)
TODO: come salvare una configurazione del genere?
venerdì 4 gennaio 2008
phedex test widget up & running
Lo scheletro per tutti i widget è pronto. Documentazione successiva perché sono ancora incerta sulla quantità di interazione tra javascript e php a livello client.
Idea:
(NameOfService)DefaultConfig.xml: file statico di configurazione
(NameOfService)DynamicTemplate.txt: file di testo con le informazioni
(NameOfService)Nazgul.pl (cron):
-prende:
(NameOfService)Config.xml e rielabora le informazioni statiche,
(NameOfService)DynamicTemplate.txt per la parte iniziale del file xml, aggiunge le informazioni dinamiche recuperate dalla ui
-produce:
(NameOfService).xml
----------FINE PARTE PROPRIA DEL NOSTRO T2 (~can fudge it more), INIZIO PARTE RICICLABILE
(NameOfService).xml: file xml con determinate informazioni necessarie, standardizzato per ogni possibile tipo di Service
(NameOfService)Shadowfax.php (chiamato da HTML):
-prende:
(NameOfService).xml, fa echo delle informazioni farcendole con tag html / codice javascript
-produce:
QUI CI SONO DUE POSSIBILITA':
1. codice HTML da infilare direttamente nella pagina di layout
2. javascript da rielaborare (es. codice javascript con array di risultati ritornato)
Nel caso di Phedex (Ganglia), i due metodi sono ~equivalenti (credo), vantaggi e svantaggi:
1CON. bisogna riparsare l'xml ogni volta che si ha un grafico nuovo e vedere con che parametri (POST) è stato chiamato. L'xml è piccolopiccolo
1PRO. è semplicissimo
2CON.più sporcizia javascript in giro per l'HTML
2PRO.si parsa una volta sola
2PRO.quando le cose si fanno più complicate (es. query Redacle) è più estendibile
Per il metodo 1 basta aggiungere informazioni a xml di config e gli altri grafici vengono gratis. Quindi implemento il secondo.
TOCHECK: Model View Controller?
Idea:
(NameOfService)DefaultConfig.xml: file statico di configurazione
(NameOfService)DynamicTemplate.txt: file di testo con le informazioni
(NameOfService)Nazgul.pl (cron):
-prende:
(NameOfService)Config.xml e rielabora le informazioni statiche,
(NameOfService)DynamicTemplate.txt per la parte iniziale del file xml, aggiunge le informazioni dinamiche recuperate dalla ui
-produce:
(NameOfService).xml
----------FINE PARTE PROPRIA DEL NOSTRO T2 (~can fudge it more), INIZIO PARTE RICICLABILE
(NameOfService).xml: file xml con determinate informazioni necessarie, standardizzato per ogni possibile tipo di Service
(NameOfService)Shadowfax.php (chiamato da HTML):
-prende:
(NameOfService).xml, fa echo delle informazioni farcendole con tag html / codice javascript
-produce:
QUI CI SONO DUE POSSIBILITA':
1. codice HTML da infilare direttamente nella pagina di layout
2. javascript da rielaborare (es. codice javascript con array di risultati ritornato)
Nel caso di Phedex (Ganglia), i due metodi sono ~equivalenti (credo), vantaggi e svantaggi:
1CON. bisogna riparsare l'xml ogni volta che si ha un grafico nuovo e vedere con che parametri (POST) è stato chiamato. L'xml è piccolopiccolo
1PRO. è semplicissimo
2CON.più sporcizia javascript in giro per l'HTML
2PRO.si parsa una volta sola
2PRO.quando le cose si fanno più complicate (es. query Redacle) è più estendibile
Per il metodo 1 basta aggiungere informazioni a xml di config e gli altri grafici vengono gratis. Quindi implemento il secondo.
TOCHECK: Model View Controller?
mercoledì 2 gennaio 2008
one more tutorial
per il php è più conveniente usare semplicemente il parser altrimenti divento pazza con xlst
http://www.developertutorials.com/tutorials/php/parsing-xml-using-php4-050816/
http://www.developertutorials.com/tutorials/php/parsing-xml-using-php4-050816/
martedì 1 gennaio 2008
update del nuovo anno
altrimenti mi dimentico cosa sto facendo. sto sempre lavorando sullo script perl di phedex e sto sperimentando il possibile.
installati (via cpan):
xml::xpath
text::trim (removes trailing spaces)
evviva cpan.
Per le informazioni dinamiche che devono essere pescate al momento (es. data corrente) ho pensato a un altro XLST stylesheet, dinamico (vs quello statico) per evitare schifezze di parsing in perl. Disaccoppiare, disaccoppiare. Il trasformatore Sablotron prende in input l'XML generato dallo stylesheet statico (del tipo, ) e attacca a imgurl il pezzo necessario (span, startdate, enddate) allo script python dei GraphTools che genera l'immagine
installati (via cpan):
xml::xpath
text::trim (removes trailing spaces)
evviva cpan.
Per le informazioni dinamiche che devono essere pescate al momento (es. data corrente) ho pensato a un altro XLST stylesheet, dinamico (vs quello statico) per evitare schifezze di parsing in perl. Disaccoppiare, disaccoppiare. Il trasformatore Sablotron prende in input l'XML generato dallo stylesheet statico (del tipo
lunedì 10 dicembre 2007
da installare per sablotron
expat (http://expat.sourceforge.net/)
sablotron (http://www.gingerall.org/sablotron.html)
perl sablotron (http://search.cpan.org/~pavelh/XML-Sablotron-1.01/Sablotron.pm#Object_Interface)
tutti tranquillamente con ./configure, make, make install, make clean
sablotron (http://www.gingerall.org/sablotron.html)
perl sablotron (http://search.cpan.org/~pavelh/XML-Sablotron-1.01/Sablotron.pm#Object_Interface)
tutti tranquillamente con ./configure, make, make install, make clean
Iscriviti a:
Post (Atom)