Flatnux next

[Alessandro Vernassa]

Negli ultimi giorni � comparsa una nuova sezione nell'area download chiamata
Flatnux_next.

Questa cartella contiene quella che potrebbe diventare Flatnux2.
Questa versione � stata riscritta completamente da zero e non � ancora adatta
per essere utilizzata su siti di produzione.
Inoltre � ancora allo stato minimale.
Pu� comunque servire per avere un'idea di come andr� avanti il progetto e per
fornire idee e suggerimenti.

ecco le cose che dovrebbe avere in pi� rispetto a Flatnux
-possibilit� di avere sezioni e blocchi visibili per un certo un arco di tempo
-supporto blocchi all'interno di una sezione
-traduzioni tramite files csv modificabili da excel
-configurazione delle sezioni e del cms su tabelle xmldb
-semplificazione creazione dei temi, blocchi e sezioni
-possibilit� di poter ridefinire i criteri di autenticazione
-unica cartella scrivibile
-importazione come sezioni di pagine web salvate in locale
-supporto completo all'xhtml
-funzioni ajax

Alessandro

[John D'Orazio]

Ho provato su un sito di test, appena finito l'aggiornamento mi esce subito errore di preg_match non supporta "." o qualcosa del genere, poi avviene il redirect per confermare le configurazioni iniziali ma anche lì errore:

Call to undefined function sectionlocation() in /membri/johnrdorazio/SitoFlatnukePersonale/include/dynamic.php on line 46

[Alessandro Vernassa]

Purtroppo è possibile soltanto installare tutto da zero.

Si tratta di una versione riscritta completamente e quindi incompatibile con il Flatnux classico

Alessandro

[John D'Orazio]

Ok capisco, ho fatto l'installazione ex novo, alla fine della registrazione dell'account amministratore è uscito un errore unlink che non so se è importante o no.

Poi cliccando sulla lingua inglese escono diversi errori: Undefined index: title_en in /membri/johnrdorazio/SitoFlatnukePersonale/include/functions.php on line 980

[John D'Orazio]

E' ancora possibile attivare l'opzione "FORCE" (o "FORZA") per mod_rewrite? Perché i server altervista non riconoscono <if module> ecc.

[John D'Orazio]

Giacché la nuova versione sta in via di sviluppo, si può considerare di ampliare le possibilità per i "gruppi", cioè estendere la creazione dei gruppi agli utenti? Questo faciliterebbe funzioni sociali su un sito flatnux. Bisognerebbe allora tenere conto di chi ha creato quale gruppo (anche qui allora campo "autore" o "creatore"), e eventualmente la possibilità di invitare altri utenti del sito ad un gruppo.

[John D'Orazio]

Ottimo il menu "dropdown", a comparsa!

[John D'Orazio]

vedo che tutto il pannello di controllo è basato ora sul xmldb. Ma non rimarrà questa visualizzazione a tabella no? Questo dovrebbe essere una funzione accessibile per "utenti esperti", ma dovrebbe rimanere un'interfaccia grafica che è più user-friendly. Così anche per l'amministrazione delle news, degli utenti, dei gruppi, e via dicendo. Si potrebbe fare il paragone in Microsoft Access tra le tabelle e le maschere. L'amministrazione ordinaria avviene con l'interfaccia grafica, come in Access l'inserimento dei dati avviene ordinariamente attraverso la maschera (Form-view). Poi c'è sempre la possibilità di vedere che cosa esattamente c'è sotto, con una tabella basata sul xmldb, come in Access c'è anche la Table-view.

[John D'Orazio]

Ho scritto un post di blog sulla nuova versione in elaborazione...

http://johnromanodorazio.blogspot.com/

[John D'Orazio]

Suggerirei anche di migrare charset al UTF-8 che ormai sta diventando lo standard per l'internazionalità, con un unico charset sono supportate tutte le lingue del mondo. Quando è dichiarato esplicitamente è supportato da tutti i browser, e ormai tutti gli API "maggiori" inviano i dati codificati con charset UTF-8. E' diventato pure lo standard per il javascript (il javascript utilizza di default i caratteri unicode).

Questo significa che i file linguistici di flatnux dovrebbero essere salvati con utf-8. Ormai tutti i maggiori editor di testo supportano utf-8 (attenzione però a non utilizzare il BOM, che non è ancora supportato dai browser!) Io per esempio ultimamante utilizzo molto pspad e aptana studio ed è facilissimo settare i salvataggi a utf-8. Mentre alcuni editor hanno difficoltà a tradurre un documento iso e salvarlo in utf-8 senza creare caratteri strani, pspad e aptana invece non hanno alcuna difficoltà a tradurre correttamente i caratteri.

Se non si vuole fare come scelta di fondo del CMS, darei almeno la possibilità di scegliere il charset dalla configurazione. Questo significherebbe però offrire i file linguistici separatamente dal CMS, quasi come un plugin, dando la scelta tra quelli che hanno encoding iso e quelli che hanno encoding utf-8.

Forse non è male l'idea di offrire i file linguistici separatamente dal core del CMS e dagli aggiornamenti del CMS, in questo modo se qualcuno personalizza i files linguistici non verranno sovrascritti con gli aggiornamenti a meno che decida di scaricare i "pacchetti linguistici". Potrebbe essere una buona scelta avere "pacchetti linguistici" separati, scaricabili a parte.

Ma credo che in ogni modo la scelta migliore è quella di adottare l'UTF-8 che alla fine non crea problemi di encoding ma li risolve.

Voi altri amministratori / sviluppatori (se ci siete) che ne pensate?

[Alessandro Vernassa]

Il charset da utilizzare dipende giￜ dalla lingua.

Su Flatnux ￜ definito in languages/xx.php

Il russo per esempio ￜ in utf-8
alla linea di languages/ru.php ￜ presente:
define("_CHARSET","UTF-8");

Sul FN-next sarￜ definito in languages/xx.csv in questo modo:

"id","text"
"_LANGUAGE","Italiano"
"_CHARSET","ISO-8859-1"
"sunday","Domenica"
"monday","Lunedￜ"
[....]

la comoditￜ sarￜ quella di poter aprire il file con excel e modificarlo per
creare una nuova traduzione.

lato sviluppatore, per rendere una stringa traducibile, sarￜ sufficiente
scrivere:

FN_i18n("my string");

e aggiungere una riga alla tabella nel file csv all'interno del blocco o
della una sezione.
Se la riga non esiste sarￜ visualizzato il messaggio originale in inglese

Alessandro

Alle venerdￜ 4 febbraio 2011, John D'Orazio ha scritto:
> Suggerirei anche di migrare charset al UTF-8 che ormai sta diventando lo

> standard per l'internazionalitￜ, con un unico charset sono supportate tutte
> le lingue del mondo. Quando ￜ dichiarato esplicitamente ￜ supportato da

> tutti i browser, e ormai tutti gli API "maggiori" inviano i dati codificati
> con charset UTF-8. E' diventato pure lo standard per il javascript (il
> javascript utilizza di default i caratteri unicode).
>
> Questo significa che i file linguistici di flatnux dovrebbero essere
> salvati con utf-8. Ormai tutti i maggiori editor di testo supportano utf-8

> (attenzione perￜ a non utilizzare il BOM, che non ￜ ancora supportato dai

> browser!) Io per esempio ultimamante utilizzo molto pspad e aptana studio

> ed ￜ facilissimo settare i salvataggi a utf-8. Mentre alcuni editor hanno
> difficoltￜ a tradurre un documento iso e salvarlo in utf-8 senza creare
> caratteri strani, pspad e aptana invece non hanno alcuna difficoltￜ a

> tradurre correttamente i caratteri.
>
> Se non si vuole fare come scelta di fondo del CMS, darei almeno la

> possibilitￜ di scegliere il charset dalla configurazione. Questo
> significherebbe perￜ offrire i file linguistici separatamente dal CMS,

> quasi come un plugin, dando la scelta tra quelli che hanno encoding iso e
> quelli che hanno encoding utf-8.
>

> Forse non ￜ male l'idea di offrire i file linguistici separatamente dal

> core del CMS e dagli aggiornamenti del CMS, in questo modo se qualcuno
> personalizza i files linguistici non verranno sovrascritti con gli
> aggiornamenti a meno che decida di scaricare i "pacchetti linguistici".
> Potrebbe essere una buona scelta avere "pacchetti linguistici" separati,
> scaricabili a parte.
>

> Ma credo che in ogni modo la scelta migliore ￜ quella di adottare l'UTF-8

[John D'Orazio]

Infatti mi riferivo a languages/it.php, come anche fr.php, es.php ecc. sono tutti in charset ISO. Invece credo che sarebbe meglio utilizzare UTF-8 per tutte le lingue. E' compatibile con tutte le lingue.

Siccome utilizzo UTF-8 su tutti i miei siti, modificavo manualmente it.php, fr.php, es.php ecc. e cambiavo tutti in charset UTF-8. Cambiavo la costante "_CHARSET" da ISO-8859-1 a UTF-8 poi risalvavo il file con charset UTF-8. Soltanto che con ogni aggiornamento del CMS veniva ri-scritto in ISO-8859-1. Penso che sarebbe meglio utilizzare l'UTF-8, ma suppongo che se qualcuno preferisce utilizzare ancora ISO basterebbe che i files delle lingue non siano sempre incluse negli aggiornamenti del CMS, se sono dei pacchetti a parte allora ognuno li può modificare a piacimento senza che siano sovrascritti...

[John D'Orazio]

Suggerirei anche di utilizzare uno spritemap per le "bandiere" delle lingue. Utilizzare gli spritemap riduce le richieste e i trasferimenti client-server e velocizza così il caricamento della pagina.

[John D'Orazio]

Questo significa anche creare le regole css che puntano alle esatte posizioni sullo spritemap per le singole bandiere. Io ho adottato questo metodo nel mio tema open-social ("glorioso"). Si trovano diversi esempi già pronti da implementare, per esempio:

http://tayles.tumblr.com/post/321497631/flags-css-sprite

http://www.jackrebel.com/category/icons/page/5/

http://www.bloggertips.rr.nu/2010/11/another-google-translate-widget-with.html

http://www.howtoweb.it/tutorial/realizzare-select-multilingue-con-jquery/

Quello che mi piace di questo esempio su github è che si può scegliere tra 16px e 32px.