[CMS] Amministrazione via web o client standalone?

[daniele_dll]

hola,

faccio una domandina anch'io, anche se un po complessa, quindi vi prego di leggere con una certa attenzione

Come molti sanno, e per chi non lo sa, sto da tempo portando avanti un CMS abbastanza flessibile e, proprio per questo, voglio offrire il massimo per chi lo userà

Per poter fare questo ho pensato alla possibilità di realizzare un backend invece che WEB, quindi sviluppato in PHP che funzioni tramite browser, un client in C# che, tramite XML-RPC, comunichi al backend in php.

Questo è un suntino, però ora espongono alcuni dettagli per togliere ovviamente alcuni dubbi:
- Portabilità, si ovviamente il client girerà su linux anche grazie a mono
- Gestibile da dovunque, anche qui ovviamente si ... avevo in mente di dare la possibilità di eseguire il login al pannello di amministrazione normalmente via browser, ma una volta arrivati li, volevo dare la possibilità di scaricare il client per il sistema apposito e di scaricare la configurazione per la connessione [chiave di crittografia ssl, dati di accesso, path di accesso, chiave di codifica se non è usato l'ssl e cosi via]
- Non cambia il metodo di sviluppo, nel senso che chi realizzerà moduli per il mio CMS non dovrà sviluppare codice C# ma normalmente codice php che invece di buttare fuori html/xhtml dovrà buttare fuori SFML (ovvero Simple Forms Markup Language) [ LEGGERE DOPO ], cosa che grazie al sistema di template praticamente sarà quasi trasparente

A questo punto ho anche un'altra domanda da porre: utilizzare come consigliato dal paiolo un subset di XHTML, comunque notevolmente modificato perché va tolta parecchia roba e ne va aggiunta altra, oppure utilizzare un markup language create da me per l'occasione? O al limite utilizzare XForms?
Quest'ultimo lo conosco di striscio e lo andrò a studiare un po prima di prendere una scelta, comunque considerate che in tutti i casi sarà possibile inserire blocchi di codice javascript da collegare agli eventi [questo non sarà possibile farlo subito perché sto aspettando una cosa dalla mozilla foundation ]

mmmmmm credo di aver finito ... leggete e consigliate con la coscenza sulle mani DDD

------

UPDATE: stavo riflettendo sull'eventuale possibilità di sfruttare una versione semplificata di XUL con qualche leggera aggiunta per evitare l'utilizzo di javascript al massimo, ma comunque eseguite in un namespace a parte (se po fa?)

UPDATE2: oppure alla possibilità di utilizzare GECKO, XUL e JS per realizzare l'interfaccia utente in modo da permettere ai moduli client di avere una certa flessibilità e poi di esporre delle funzionialità C# per accedere al backend al javascript per è probabile che il fattore accessibilità vada a farsi benedire

------

Ci sono tutta una serie di vantaggi non indifferenti:
- Utilizzando C# su windows ottengo ottime performance grafiche e non ed in aggiunta posso farlo girare su linux e mac os x tramite mono, anche se con performance ridotte ma comunque superiori a quelle di una pagina web piena di JS che pianta il browser
- Tramite un applicativo vero e proprio, usando poi C#, l'accessibilità è gestita in toto dal sistema, il lavoro che devo fare per implementarla è veramente nullo e si adatta in base al sistema senza quindi ingigantire nulla e niente
- Possibilità di UNDO/REDO fin quando i cambiamenti non vengono inviati
- Possibilità di interfacciarsi con un software installato sulla macchina per fare importazioni/esportazioni di dati invece di metterci una macchina di mezzo che faccio ciò, ergo costi ridotti per il cliente, magari aggiungendo un tool per farle in automatico queste operazioni
- Interfaccia grafica fluida e dinamica rispetto a quella web che comunque sarebbe stata notevolmente ridotta per via dell'accessibilità
- Supporto comunque di javascript per dare una certa flessibilità agli sviluppatori

e poi c'è altra roba ancora

[andrea.paiola]

ho chiesto su un altro forum e su webaccessibile... poi magari riporto qua cosa dicono

prima risposta da parte di Diego La Monica
Ciao Andrea,
la soluzione è fattibile ed ho fatto qualcosa di analogo (solo di test e non con C# ma con Visual Basic 6) diversi anni fa.
Più che altro per slegarmi dai problemi di sicurezza che un sistema web in genere presenta.
Il problema però si presenta nel momento in cui il CMS deve essere gestito da più utenti. Devi provvedere ad una procedura di installazione, prevedere aggiornamenti di tutti i client in caso di bug-fixing o di nuove funzionalità, ecc. ecc. Problematiche ormai note per gli sviluppatori windows: "dll hell".
Insomma, un lavoro non da poco ma fattibile. Di al tuo amico di tenere in considerazione i tempi di manutenzione successiva ed il costo che questi possono cagionare.

[daniele_dll]

visto, come vedi ti hanno risposto per l'appunto che la cosa è fattibile e possibilmente qualche altro ti dirà che è interessante

in realtà il problema relativo al "dll hell" non lo ho, perché essendo in C# al massimo ho .NET hell, ma nemmeno quello perché gli unici componenti che non saranno quelli del sistema sono tutti miei e saranno aggiornati tramite un sistema di update automatico che ho già scritto e uso in un software, anche se fino ad adesso ho rilasciato solo 2 aggiornamenti

Per i tempi di manuntenzione, il problema è abbastanza ridotto, infatti è mia intenzione non realizzare un client in C# con dentro la gui dei moduli ma realizzare un client in C# che recuperi la gui on the fly tramite apposite richieste riducendo notevolmente il problema manutenzione: infatti basta aggiornare i file che contengono il come costruire la gui

Per i costi ... beh ... quelli di startup sono sicuramente superiori alla realizzazione di codice html, però se va considerato che dovrei fare 2/3 interfacce html alla fin fine preferisco spendere un po più all'inizio, come per altro sto facendo sul resto del cms, che combattere dopo con problemi assurdi

[andrea.paiola]

si però non ti aspettare che riporto quanto scrivi
io ti ho messo in comunicazione con chi ne sa più di me ( io non ci avevo proprio mai pensato ), ora ti arrangi
il thread su webaccessibile è questo http://itlists.org/pipermail/webacce...ry/021710.html

[daniele_dll]

^^

ora che hai postato il link ci penso io

[daniele_dll]

Ah, un altro fattore non indifferente è la possibilità di stampare report in maniera flessibile, infatti dato che si conosce il contenuto di ogni singola riga posso permettere l'evidenziazione sul client delle varie righe, come anche la selezione di quelle che si vogliono stampare ed altra roba ancora senza diventare scemo nello stesso tempo

[Laburno]

Ciao Daniele,
ti posso fare una domanda da niubbo estremo?
Che vantaggi ci sono, oltre presumo alla sicurezza, di gestire l'amministrazione via client o via interfaccia web?

[daniele_dll]

Sono scritti nel primo post e in quello subito sopra il tuo, per quanto riguarda la stampa, almeno lato utente

Lato sviluppatore, invece, devi avere a che fare solo con un "render engine" quindi meno rogne ed in aggiunta hai il lavoro semplificato, infatti il numero di "informazioni da inserire" per creare una pagina è sufficentemente ridotto e semplificato, almeno in questo caso.

[TheVice]

Ciao, secondo me l'utilizzo di un client apposito non è una scelta giusta (per ora) perchè per ogni modifica rischi che anche il client debba essere modificato a + riprese e dal punto di vista "logistico" man mano che cresce l'utenza diventa piuttosto complicata la cosa.
Io direi di andare interamente di gestione web, soprattutto all'inizio, perchè è lì che distribuirai maggiori update e + alta potrebbe essere la percentuale di problemi.
Il client lo penserei come miglioria di un progetto dalla base assestata dall'uso di un buon numero di utenti.

[daniele_dll]

Ciao, secondo me l'utilizzo di un client apposito non è una scelta giusta (per ora) perchè per ogni modifica rischi che anche il client debba essere modificato a + riprese e dal punto di vista "logistico" man mano che cresce l'utenza diventa piuttosto complicata la cosa.
Io direi di andare interamente di gestione web, soprattutto all'inizio, perchè è lì che distribuirai maggiori update e + alta potrebbe essere la percentuale di problemi.
Il client lo penserei come miglioria di un progetto dalla base assestata dall'uso di un buon numero di utenti.

Beh, quello è uno dei problemi che sicuramente non avrò

Infatti il client non dovrà far altro che leggere le informazioni su come costruire l'interfaccia, leggere le informazioni su cosa inserire nell'interfaccia e al momento dell'operazione richeista (modifica, cancella, aggiungi, evidenzia e cosi via), molto semplicemente, se ha dati da inviare perché è stato cliccato un form o se si tratta di un link invia al richiesta in get senza allegare nessuna richiesta xml-rpc e scarica le nuove informazioni per poi ricominciare il ciclo logico delle informazioni

tutto sarà gestito ovviamente a lato server, anche la creazione dell'interfaccia dato che questa verrà spedita, in modo che il client deve solo visualizzare i dati che gli arrivano per come gli viene detto e poi rispedire indietro le informazioni richieste

[Siggy]

tutto sarà gestito ovviamente a lato server, anche la creazione dell'interfaccia dato che questa verrà spedita, in modo che il client deve solo visualizzare i dati che gli arrivano per come gli viene detto e poi rispedire indietro le informazioni richieste

Hum,
questo non comporta un elevato traffico di dati tra il client e il server?

Sarebbe stata carina anche una versione mobile (palmari/cellulari), ma se hai un'elevato traffico di dati diventa impossibile da gestire su connessioni gsm/dialup/gprs...

sarebbe un peccato

[daniele_dll]

Hum,
questo non comporta un elevato traffico di dati tra il client e il server?

Sarebbe stata carina anche una versione mobile (palmari/cellulari), ma se hai un'elevato traffico di dati diventa impossibile da gestire su connessioni gsm/dialup/gprs...

sarebbe un peccato

No, anzi, considera che il traffico sarà inferiore perché una parte dei dati, per la precisione la parte che riguarda la costruzione dell'interfaccia viene spedita una sola volta e poi viene verificata tramite apposito checksum (md5/sha1) in questo modo ci saranno 40 byte o 32 byte, oltre alla richiesta, per "pagina" utilizzata dal modulo, dopo il primo download, di conseguenza il traffico li è ridotto

ed in aggiunta tutto il contenuto verrà trasferito gzippato in modo da risparmiare sulla banda

Ora che mi ci stai facendo pensare, sviluppando il client in C#, separando bene il render engine dall'utilizzo diretto dei forms, ergo un backend specifico per la creazione dell'interfaccia andrebbe usato, può essere buttato con tranquillità sui palmari che montano win ce

l'unica cosa che vorrei verificare è un sistemino tipo di one-key-password in modo da non mandare al server mai la password ma un valore encodato con essa in modo che il server sappia decodificarla senza però riceverla

devo vedere un po ... ovviamente la one-time-password che genera il sistema ha una scadenza ben precisa

Me ne parlava ieri antrea (di www.3site.eu): aveva trovato per un web un apparecchio in grado di generare una password numerica di 6 cifre che avesse una massima durata di 60 secondi e veniva inserita solo quella, di conseguenza anche se doevsserò recuperare il codice non sapendo mai il contenuto esatto, dato che è variabile, non è possibile nemmeno ottenere l'hash con cui andrei a codificare il valore variabile

Vi sembra una cosa fattibile? Però quello che ne viene fuori deve essere veramente corto altrimenti mi mangio metà del traffico solo per l'autenticazione

[daniele_dll]

dai su su spremete le meningi

[andrea.paiola]

per quanto riguarda il controllo degli aggiornamenti usa md5
per il controllo "one key password", come la chiami tu, mi sembra che ti serva crittografia a chiave pubblica e quindi ti consiglio PGP

[ceccus]

Salve,
Scusa...riassumo brevemente per vedere se ho capito...
Praticamente vorresti creare una procedura lato client NON Web che permetta la configurazione del CMS ... è così o ho capito male ?

Ciao !!