Help: correzione codice

già, ma è il minore dei mali :D
La soluzione migliore sarebbe creare un modulo ceh faccia uso fi form_alter per andare a sistemare le cose che servono + alcune funzioni di temizzazione per andare a sistemare la visualizzazione, poi è ovvio anche che se uno usa un modulo derivante da un altro su cui hanno trovato dei bug come minimo dovrebbe andare a controllare se anche il suo è afflitto e vedere se andare a metterci mano. :D

mavimo wrote:

poi è ovvio anche che se uno usa un modulo derivante da un altro su cui hanno trovato dei bug come minimo dovrebbe andare a controllare se anche il suo è afflitto e vedere se andare a metterci mano. :D

Quel che voglio dire è che se decido di variare il modulo node, in futuro sono incasinato con gli aggiornamenti. Ma sono i soliti identici casini che mi ritrovo se sdoppio il modulo. In entrambi i casi devi andare a vedere le modifice del node.module e riapplicarle al nuovo modulo (o al modulo node.module variato)....ma se devi andare a vedere le modifiche e riapplicarle sul tuo modulo sdoppiato.... tanto vale non sdoppiarlo, almeno ho una rogna in meno ;-)

Ovviamente sono vedute differenti :-) , ma personalmente, se devo fare variazioni sul nodo, preferisco di gran lunga creare un nuovo tipo di nodo ed ereditare tutto dal nodo standard (in questo modo non ho doppio codice, ma un codice unico gestito da node.module + il codice personalizzato per il nuovo tipo che lo posso personalizzare come meglio credo). Il mio nuovo tipo di modulo, erediterà anche tutte le "proprietà" del nodo (se metto il modulo upload, il modulo tiny o quant'altro)

Comunque sia, per la modifica di un link (come nel caso specifico), la soluzione è agire sul template del nodo (comodo ed indolore :-) ) o, se si vuol andare di fino, sbizzarendoci anche sulla singola pagina, si può andare a variare template.php, decidendo i singoli tempalate da lanciare a seconda del caso.

Ciao
Gianni

giannigiusti wrote:

Quel che voglio dire è che se decido di variare il modulo node, in futuro sono incasinato con gli aggiornamenti. Ma sono i soliti identici casini che mi ritrovo se sdoppio il modulo. In entrambi i casi devi andare a vedere le modifice del node.module e riapplicarle al nuovo modulo (o al modulo node.module variato)....ma se devi andare a vedere le modifiche e riapplicarle sul tuo modulo sdoppiato.... tanto vale non sdoppiarlo, almeno ho una rogna in meno ;-)

Pienamente d'accordo, solo ceh clonando il nodo e facendo le modifiche sul nodo copia non influisco sul funzionamento di altri nodi che potrebbero appoggiarsi a node (moduli decisamente molto usato :D )

giannigiusti wrote:

Ovviamente sono vedute differenti :-) , ma personalmente, se devo fare variazioni sul nodo, preferisco di gran lunga creare un nuovo tipo di nodo ed ereditare tutto dal nodo standard (in questo modo non ho doppio codice, ma un codice unico gestito da node.module + il codice personalizzato per il nuovo tipo che lo posso personalizzare come meglio credo). Il mio nuovo tipo di modulo, erediterà anche tutte le "proprietà" del nodo (se metto il modulo upload, il modulo tiny o quant'altro)

Anche io, ed è quello che consiglio a chiunque abbia un minimo di conoscenze di fare, solo ceh dato che poichè l'utente non sapeva concatenare due string (e per suea ammissione non conosce PHP) dirgli di svilupparsi un modulo come minimo lo avrebbe sconvolto :D

giannigiusti wrote:

Comunque sia, per la modifica di un link (come nel caso specifico), la soluzione è agire sul template del nodo (comodo ed indolore :-) ) o, se si vuol andare di fino, sbizzarendoci anche sulla singola pagina, si può andare a variare template.php, decidendo i singoli tempalate da lanciare a seconda del caso.

Perfettamente d'accordo (quando possibile).

luisasasi wrote:

Gasp! Non pensavo di causare un guaio tanto grosso! Ringrazio tutti.

Ma quale guaio? Io stimo mavimo e non vedo insulti nei nostri post :-)
Ho esperesso solamente la mia personale opinione circa l'inutilità di copiare il modulo node, solo per variare un link, quando la cosa si può fare via template...... ma ho messo molti IMO e molte faccine.... come dire "opinione personale e senza offesa".
A me sembra normale scambiare opinioni e vedute tra programmatori.... è una delle basi dell' OpenSource e non credo che mavimo si sia risentito. :-)

luisasasi wrote:

Ora, non so bene come funzionano gli aggiornamenti, ma se ho ben capito, tutte le volte che si fa un aggiornamento sicurezza segnalato da Drupal.org, debbo rimodificare il modulo. Creo ulteriori bug?
Grazie a tutti

Brava.... questa è già una via accettabile rispetto al copiare un modulo (anche se personalmente NON la seguirei perchè del tutto illogica rispetto alla filosofia di Drupal). Ma considera anche la via elegante che è quella che ti ho postato (riveduta e corretta):

.... al posto di:

metti:

e dovresti raggiungere il tuo scopo senza scomodare modifiche sul codice.

P.S.
X mavimo.... rispondo solo ad una tua riga.
Anche se fai un nuovo tipo di nodo, non influenzi gli altri nodi, inoltre puoi definire nuove proprietà (un giorno, giuro che faccio un piccolo tutorial).
Io trovo, la nostra discussione interessante.... ce ne fosse di gente come te, con cui posso scambiare opinioni di programmazione dei moduli!!! In questo forum qualcuno che personalizza moduli c'è, ma siamo in pochi. Mi sembrerebbe stupido non discutere di problematiche come quella venuta fuori in questo post :-)

Ciao
Gianni

Confermo che non mi sono offeso (casomi ce ne fosse bsogno :P ), ma anzi...

Pre quanto riguarda il fatto che non influenzi altri nodi andando ad agire sul modulo node non lo trovo proprio corretto... nel senso che poichè ogni cosa è un nodo anche modifiche che sono banali potrebbero andare a influire con le funzionalità di qualche modulo, ovvio poi che più le modifiche sono pesanti tanto più è facile che influisca con altro.

Per esempio alcuni moduli dipendo in maniera esplicita da altri (Forum richiede Taxonomy tanto per citarne uno), quindi finché si tratta di modifcare la funzione di theming la probabilità di fare danno è minima, ma se vado ad agire su altre funzioni.. chi può saperlo? Per questo motivo IMHO è meglio duplicare il nodo in modo che si lascia la versione originale al suo posto così se qualche altro modulo si appoggia ad esso non faccio danno, mentre sulla copia posso fare tutte le modifche del caso senza farmi paranoi sui possibili risultati e limitanto i possibili probemi; ovvio che devo avee un idea di cosa faccio, altrimenti potrei cancellare record dall tabella errata e quindi tanto vale :D

Nel caso specifico la cosa migliore è agire sulle funzioni di theming, in altri casi consiglierei di scrivereun modulo, ma ècomunque necessario ceh l'utente sappia farlo, altrmenti la via meno pericolosa èl cpia edl modulo e Find & Replace per rearne la copia funzionante ;)

mavimo wrote:

Pre quanto riguarda il fatto che non influenzi altri nodi andando ad agire sul modulo node non lo trovo proprio corretto... nel senso che poichè ogni cosa è un nodo anche modifiche che sono banali potrebbero andare a influire con le funzionalità di qualche modulo, ovvio poi che più le modifiche sono pesanti tanto più è facile che influisca con altro.

Ma infatti tu NON modifichi il nodo, ma ne erediti le proprietà ed i metodi, creando una nuova tipologia di nodo. Immagina la programmazione ad oggetti, rapportata a Drupal (che poi di questo si parla). Come da una classe puoi crearne una nuova che eredita le proprietà ed i metodi del padre... allo stesso modo, con drupal, tu puoi fare una nuova tipologia di nodo che eredita le proprietà ed i metodi del nodo padre. Se al nodo "padre" (chiamiamolo così), aggiungi nuove proprietà, te le ritrovi nel nodo figlio..... se qualcosa cambia nel nodo padre, la variazione si ripercuote nel figlio. Il contrario NON è vero.
Giusto per farti un esempio concreto: devo creare un tipo di pagina che ha in più N campi, chessò: data di inizio validità e data di fine validità (voglio far in modo che QUELLE pagine siano visualizzate per un periodo che voglio io)..... come faccio?
1) vario node.module .....e vabbè, fin quì siamo entrambi d'accordo che non è il sistema giusto :-)
2) sdoppi node.module e cambi il suo interno..... ok, funziona, però ti ritrovi tutta una serie di funzioni IDENTICHE con nomi diversi. Oltretutto se c'è un bug su node.module, te lo ritrovi anche sul tuo modulo
3) crei un nuovo tipo di nodo chiamato "pagina con scadenza". Questa userà le funzioni del nodo, a cui aggiungeremo una serie di campi ed una funzione per verificarne la scadenza. Non ho funzioni doppie, eredito le proprietà ed i metodi del nodo e, se nel nodo correggono qualcosa, si ripercuote anche nel mio. Tuttavia, il mio nuovo nodo, non può influire su node.module (se non di proposto.... ma non son masochista :-) )

Da nessuna parte troverai scritto di sdoppiare node.module per variarne le proprietà, ma casomai di creare una nuova tipologia. Ed una nuova tipologia, prevede un numero estremamente ridotto di funzioni, perchè molte sono già "proprietà" e "metodi" di tutti i nodi.... si tratta di aggiungere quelle proprietà e metodi nuovi, di cui, quel nodo specifico, ha bisogno. Quest'esempio è chiarissimo:
http://api.drupal.org/?q=api/file/developer/examples/node_example.module/5

La forza di drupal stà proprio nel suo paradigna ad oggetti...... drupal non è scritto in con oggetti e classi, ma la sua struttura lavora con le stesse filosofie. Quindi è inutile sdoppiare nodi, ma si devono estendere o crearne di nuovi partendo da padri. Drupal è un CMS ad oggetti!
Per lavoro ho dovuto creare 5 nuovi tipi di nodi: gare, contratti, telefoni, avvisi ed eventi. Capisci che sono 5 nodi che fanno le più svariate funzioni. Tutti sono figli del nodo, ma nessuno pesta i piedi all'altro, come nessuno pesta i piedi a qualsiasi altro modulo di drupal.....anzi.... essendo tutti e 5 figli del nodo, ne ereditano le proprietà così:
installato il modulo upload, questo lo posso attivare indistintamente su tutti (o su quelli che voglio), idem per tiny. La taxonomia, essendo proprietà dei nodo, è diventata anche proprietà dei miei nodi (ovviamente se l'attivo) e così pure per il nodo teaser..(non ricordo il nome), che permette di farmi il teaser personalizzato.... ma è così per tutto il resto. Se viene scoperto un bug sul nodo, non devo impazzire a variare 6 moduli.... semplicemente aggiorno drupal come ho sempre fatto.
Queste cose che scrivo, le ritrovi su un bellissimo documento di drupal che parla proprio del paradigma ad oggetti di Drupal (che ora non trovo perchè la ricerca non funziona).

IMO, è molto molto molto più probabile far grandi casini, sdoppiando il modulo node.module.... sia casini di gestione (nuovi aggiornamenti), sia casini di codice ridondante, sia casini che se nel modulo node.module, c'è un bug di sicurazza, quel bug è amplificato alla N.... sia casini nel senso che ti ritrovi N nodi di tipo uguale, il cui comportamento è condizionato da N moduli... ma quì, immagino che quando dici "sdoppiare" intendi anche creare una nuova tipologia di nodo..... e quì si ritorna sull'inutilità dello sdoppio :-) (a che serve creare una nuova tipologia e gestirla con N funzioni/api uguali?)

Ovviamente ogni uno la pensa come vuole, ma ci tenevo a dire la mia. Comunque scriverò una guida personale per dimostrare la semplicità e la flessibilità che il "paradigma ad oggetti" di drupal produce.

P.S.
Lo ridico e lo risottoscrivo a scanso di equivoci.... stimo molto Mavimo e i discorsi sopra li faccio con lui perchè lo ritengo un ottimo programmatore, con cui si può parlare anche di argomenti tecnici (invece dei soliti "mi da errore di memoria", "come si installa drupal" ecc... ecc... :-) senza offesa per nessuno.... che poi son le domade che abbiamo fatto tutti all'inizio)

Personalmente non ho altro da aggiungere..... ho fatto appositamente untesto lungo, per non tornarci sopra... non avendo altro da dire :-)

Ciao
Gianni

Mi sa che non ci siamo capiti :D

Sono d'accordo con te al 10000%, se ho scelto Drupal è proprio per la modularità e la possibilità di sfruttare (almeno in parte) i paradigmi della OOP. Detto questo si parlava se convenisse sdoppiare il modulo node e fare le modifiche su questo piuttosto che andare a modificare direttamente il modulo node originale senza sdoppiarlo. IMHO è meglio andare a creare una copia del modulo node e agire su questo proprio per non andare a inficiare il corretto funzionamento del modulo ufficiale e i moduli che si appoggiano ad esso.

Se invece parliamo del fatto che non è necessario andare a creare una copia del nodo.. bhè sono d'accordo anche io, anche perché se è necessario creare un nodo a parte si possono andare ad utilizzare tanti hook per andare a modificare il comportamento (o meglio alcune funzionalità) del nodo base senza dover apportare modifiche al modulo originale (vedo form alter tanto per dirne una).

Scusa se torno un attimo su un punto che mi sta particolarmente a cuore, anceh se sono quasi certo di andare OT :D
Drupal si basa su un concetto di OOp alquanto particolare, proprio per il fatto che non è veramente strutturato in classi. Sinceramente trovo la scelta operare con una simile strategia ha dei vantaggi, ovvero anche il primo che passa che conosce un pò il PHP ma non sa nulla dell'OOP nel giro di qualche giorno sa programmare e andare a crearsi un modulo, di contro porta a dei rallentamenti abbastanza vistosi su progetti molto ampi. Un utilizzo vero di classi sarebbe IMHO auspicabile, anche se ormai non ci spero nemmeno, inquanto si tratterebbe di riscrivere buona parte del core e mi sembra un lavoro immenso per la comunità. Un esempio banale dei vantaggi è l'uso delle funzioni di ereditarietà (e perché no anche eredità multipla :D ), che ora manca totalmente se non ricorrendo all'include più le chiamate alle funzioni, oppure il vero override delle funzioni. Usando classi template e virtual si arriverebbe ad avere una struttura dei moduli molto più razionale.

Lo scotto da pagare? Che uno deve avere veramente idea di quello che fa e non può buttare giù codice a casaccio (sinceramente quando vado a vedere il sorgente di alcuni moduli mi si accappona la pelle :D ). Ok, forse la mia visione è troppo deformata dal C++, ma credo che se si proseguisse verso una vera implementazione dell'OOP il balzo in avanti sarebbe notevole, visto che sarebbe anche il primo CMS a farlo :D

mavimo wrote:

Mi sa che non ci siamo capiti :D [...cut] e agire su questo proprio per non andare a inficiare il corretto funzionamento del modulo ufficiale e i moduli che si appoggiano ad esso.

No, ci siamo capiti, ma abbiamo visioni diverse :D
Per me NON conviene mai sdoppiare un modulo del core. Al limite creo un nuovo tipo di nodo e metto lì la mia modifica. Vabbè, opinioni diverse o fraintendimenti (il brutto di chat e forum) :-)

mavimo wrote:

Drupal si basa su un concetto di OOp alquanto particolare, proprio per il fatto che non è veramente strutturato in classi. Sinceramente trovo la scelta operare con una simile strategia ha dei vantaggi, ovvero anche il primo che passa che conosce un pò il PHP ma non sa nulla dell'OOP nel giro di qualche giorno sa programmare e andare a crearsi un modulo, di contro porta a dei rallentamenti abbastanza vistosi su progetti molto ampi.

Ovviamente non è OO, ne ha solo raccolto la visione.... ma è notevole come funziona :-P
Per la velocità hai ragione, ma purtroppo, proprio per sua natura, deve caricarsi tutti i moduli e su questi deve andare a lanciare le eventuali funzioni di hook.... se i moduli son tanti è un bel lavoro. Ci vorrebbe un sistema di razionalizzazione nel caricare i moduli ma è cosa assai difficile da fare seriamente. Riuscire ad evitare il caricamento dei moduli non utilizzati in quel momento.

mavimo wrote:

ma credo che se si proseguisse verso una vera implementazione dell'OOP il balzo in avanti sarebbe notevole, visto che sarebbe anche il primo CMS a farlo :D

Indubbiamente..... se l'OOP viene applicato ai concetti del cms.... tipo nodo = oggetto, taxonomia = oggetto e così via. Altrimenti preferisco tenermi drupal :-)
....ma la vedo dura pure io ;-)

Ciao
Gianni

@luisasasi:
Hoilà, anche a me interessa molto la questione di accessibilità e posso garantirti che con drupal e pochissimi accorgimenti si raggiunge tranquillamente il WAI-A, per l'AA e AAA le cose si complicano non poco, ma i motivi sono sopratutto dati dal fatto che non esistono temi sviluppati appositamente con questi interessi, in ogni caso tienimi aggiornato sugli sviluppi, a settembre (quando reinizierò a insegnare) avrei intenzione di realizzare un sito scolastico basato su Drupal e anche da me ci sono parecchi disabili e quindi le funzionalità di accessibilità anche per non vedenti / disabili motori mi interessano molto.

@giannigiusti:
Per quanto riguarda la velocizzazione del caricamento moduli pare che ci si arriverà con la versione 7, quando verrà abbandonata la retrocompatibilità con PHP4 con conseguente pulizia di un sacco di funzioni "sporcate" dalla necessità di usare versioni di PHP vecchie. Un articolo al riguardo era uscito un pò di tempo fa nella HP di http://drupal.org, andando a vedere gli articoli vecchi dovresti trovarlo senza troppi problemi.

scusate, ma con:

<?php
 print l('Leggi tutto...', '/node/'.$node->nid, array('title'=>$title)); 
?>

non viene fuori la seguente frase nel link?:
Leggi tutto...

mentre lei non voleva far stampare così nel link?:
Leggi tutto verbale del xx.xx.xxxx

per cui dovrebbe scrivere, se non sbaglio:

<?php
 print l('Leggi tutto '.$node->title, "node/$node->nid"); 
?>

Quote:

Non mi piace l'idea di costruire un doppio sito: uno per i detti "normali" e un altro per chi ha disabilità.

P.S.: Luisa, hai per caso qualche sito da farci vedere (sviluppato con drupal e pensato anche per persone diversamente abili)?

Quote:

per l'AA e AAA le cose si complicano non poco

I problemi che incontro con l'accessibilità e drupal, sono sostanzialmente nel rendere i temi accessibili. Drupal in se e per se restituisce solo struttura e quindi, quindi queste son per forza di cosa accessibili (escludiamo un attimo il singolo modulo e le tabelle che meritano un discorso a parte). Per i temi, io parto sempre da Aberdeen o pushbutton. Poi mi son personalizzato tinyMCE, in modo che elimini tutti i tag non XHTML strict, in modo che il redattore possa scrivere xhtml strict in modo grafico..... il problema è che poi il redattore si scorda di gestire gli acronimi, a volte il testo alternativo e il tag title, utile per restituire uteriori informazioni sui link. Un problema grosso, per quanto stupido, è il tag target dei link.... in xhtml strict (il formato preferenziale della legge.... transizionale sarebbe tollerato solo in fase di transizione tra il vecchio sito ed il nuovo), la proprietà target NON è consentita.... per fare un apertura di una nuova pagina (oltre che segnalarla) è necessario usare javascript, il che è assurdo. Per questo ho tolto del tutto aperture di nuove pagine.
Attualmente stò correggendo una marea di problemi che mi son trascinato dietro dal vecchio sito (ho 700 pagine!!! e non è stato facile riconvertirle).... finalmente son riuscito a far capire al capo l'importanza di finire tutte quelle cose che abbiamo lasciato indietro nel passaggio dal vecchio al nuovo. Verso Novembre, vi mando il link al nuovo sito, reso il più possibile accessibile, con 5 moduli che si interfacciano ad un sito istituzionale provinciale, in cui confluiscono delle informazioni centralizzate da tutti i comuni della provincia.

Anch'io non amo cambiare completamente tema per i disabili. Per ovviare a ciò, ho usato un tema liquido, strict e con colori ad un contrasto visibile a tutte le problematiche di daltonismo..... e quì ho fatto i salti mortali per trovare colori che andavano bene al capo e che fossero abbastanza contrastanti in tutte le problematiche legate ai colori. Per i ciechi mi son preoccupato nel vedere che il sito scorresse perfettamente anche senza css ed ho aggiunto un icona per ingrandire i caratteri nel caso di cataratta (ad esempio).... ho inserito anche un link per l'alto contrasto, ma dovrebbe essere inutile a questo punto... poi, appena sarà on line vi mando il link.

Ora, per quanto riguarda la dichiarazione di conformità, mi sembra che molti siano molto larghi nel autodichiararsi. Ci son siti che non raggiungono AA e si autodichiarano AAA.... tutto perchè non esiste un ente di controllo statale sui siti periferici (non esiste un ente che controlla siti scolastici/comunali/provinciali ecc...). Quello dell'autodichiarazione è una buffonata..... e non parliamo di piccoli enti, ma anche grandi strutture, come alcuni grandi comuni che si autocertificano AAA.

P.S.
Se si può fare, io sarei molto favorevole nel proporre una sezione dove ogniuno posta variazioni del codice, aggiustamenti, trucchi e consigli su come rendere accessibile drupal.... ovviamente amministratori del sito permettendo :-)

Ciao
Gianni

Per quanto riguarda al questione dell'autocertificazione mi pare sia possibile autocertificarsi solo al livello A, per l'AA e AAA serve verifica da enti predisposti (che si ciucciano un bel pò di soldi, sito da un centinaio di pagine sui 4'000,00€). Ovvio che poi uno si può autodichiarare quello che vuole, ma se viene controllato mi pare si prenda anche multe non proprio trascurabili (ok, non ci sono enti di controllo preposti, che io sappia).

Per quello che riguarda i requisiti di accessibilità della legge Stanca il problema non è tanto il generare codice XHTML Strict, quanto seguire tutte le condizioni avvini, generare i fogli di stile aural, contrasto dei colori, layout decenti fatti con CSS che non diano grossi problemi e sopratutto testarne il funzionamento con persone effettivamente affette da disabilità (gli unici che possono dare una vera risposta sulla accessibilità e usabilità).

Per quanto riguarda al possibilità di creare una sezione apposita del forum ne parlerò con Psico e vediamo cosa dice, in ogni caso approvo in pieno ;)

Per giangiusti, hai pensato di usare un software per la conversioen del contenuto delle pagine in XHTMl strict e creare uno script per prelevare e reinserire i dati nel DB? ne esiste uno ottimo open source (momentaneamente mi sfugge il nome), che funziona veramente bene, l'avevo provato e anche passando i documenti di word esportati come HTML faceva una pulizia tremenda e dava codice pulito :D

Tanto per sapere per rendere TinyMCE che fornisce soo XHTML valido intendi che ahi abilitato solo alcuni pulsanti o che hai fatto qualche modifica al codice per ottenere risultati decenti?

PS: siamo dannatamente OT nel topic, quindi per ora continuiamo qui, non appena verrà aperta una nuova sezione sposterò il tutto dall'altra parte, se invece non verrà aperta spezzerò in un altro topic.

mavimo wrote:

Per quanto riguarda al questione dell'autocertificazione mi pare sia possibile autocertificarsi solo al livello A, per l'AA e AAA serve verifica da enti predisposti (che si ciucciano un bel pò di soldi, sito da un centinaio di pagine sui 4'000,00€). Ovvio che poi uno si può autodichiarare quello che vuole, ma se viene controllato mi pare si prenda anche multe non proprio trascurabili (ok, non ci sono enti di controllo preposti, che io sappia).

A me risulta, da un convegno a cui partecipai 3 anni fa, che l'ente può autocertificarsi (come avviene nel 90% dei casi sia A, AA o AAA)...... poi, il fatto che si appoggi a qualcuno perchè il sito non è sviluppato in casa, quella è un'altra storia. Tutto sommato con l'autocertificazione non fai altro che dichiarare punto per punto, il rispetto delle singole richieste (linee guida) della Stanca. Se hai un link o qualcosa che dice che le autocertificazioni su A e AA NON son valide, potresti inviarlo così me lo leggo? (visto che non è proprio un dettaglio) :-)

mavimo wrote:

Per quello che riguarda i requisiti di accessibilità della legge Stanca il problema non è tanto il generare codice XHTML Strict, quanto seguire [cut...].

Si tratta di seguire la linea guida, rispettando quei punti (per fare un sunto breve) ;-)

mavimo wrote:

Per quanto riguarda al possibilità di creare una sezione apposita del forum ne parlerò con Psico e vediamo cosa dice, in ogni caso approvo in pieno ;)

Anche perchè, fin quando si tratta di seguire le linee guida, sin tutti buoni a leggere, il problema è poi applicare alcuni punti, su Drupal. Altro problema è capire alcuni punti "legali" della stanca e non solo quelli tecnici (mi sembra che ci sia un po' di caos, in generale sul web)

mavimo wrote:

Per giangiusti, hai pensato di usare un software per la conversioen del contenuto delle pagine in XHTMl strict e creare uno script per prelevare e reinserire i dati nel DB? ne esiste uno ottimo open source (momentaneamente mi sfugge il nome), che funziona veramente bene, l'avevo provato e anche passando i documenti di word esportati come HTML faceva una pulizia tremenda e dava codice pulito :D

Il problema è che il precedente sito si trovava su notes domino.... oltretutto una vecchia versione e non sapevo come recuperare le pagine sul suo DB. Sul sito di IBM, avevo trovato gli ODBC...... peccato che erano per versioni più aggiornate della mia. Comunque, facendo copia incolla e modificando a manina, son riuscito, insieme alla redazione del sito, a passare tutte le pagine e a correggerle quasi tutte.... col tempo poi aggiusteremo anche le ultime rimaste.

Ormai il sito è convertito..... ma mi mancano ancora alcune pagine di enti esterni a noi collegati. Che tu sappia, il software che mi accennavi, può prendere in entrata anche pagine da wget? stavo pensando "se imposto wget per scaricare le pagine a N livelli e queste le do in pasto a quel software, mi dovrei ritrovare pagine strict".... magari con link errati, ma per lo meno corrette dal punto di vista tecnico.

mavimo wrote:

Tanto per sapere per rendere TinyMCE che fornisce soo XHTML valido intendi che ahi abilitato solo alcuni pulsanti o che hai fatto qualche modifica al codice per ottenere risultati decenti?

TinyMCE, restituisce XHTML.... il problema è che non è STRICT.... però..... puoi impostare dei filtri sia a livello di tag, sia a livello di proprietà (senza variare il codice).... in questo modo, ho deciso io i tag consentiti e quelli "vietati", pur mantenedo la barra standard di tiny. In poche parole il redattore usa tinyMCE con tutti i pulsanti che voglio, ma quando mette un immagine, un link o quant'altro, le proprietà scritte al suo interno, saranno solo quelle permesse da me.... nel caso di immagini ad esempio, può smanettare quanto vuole, ma le proprietà restituite saranno solo: alt,class,height,name,src,style,title,width (questo è solo un esempio).... cioè, le sole proprietà consentite. Per prendere l'esempio del target sui link.... per "ammazzarlo" ho messo qualcosa simile a:
$init['extended_valid_elements'] = 'a[href|name|title|onclick],';

Per far ciò, ho messo in template.php:

<?php
function phptemplate_tinymce_theme($init, $textarea_name, $theme_name, $is_running) {
switch ($textarea_name) {
// Disable tinymce for these textareas
case 'log':
case 'img_assist_pages':
case 'caption':
unset($init);
break;
// Force the 'simple' theme for some of the smaller textareas.
case 'signature':
case 'site_mission':
case 'site_footer':
case 'settings][access_pages':
$init['theme'] = 'simple';
unset($init['theme_advanced_toolbar_location']);
unset($init['theme_advanced_toolbar_align']);
unset($init['theme_advanced_path_location']);
unset($init['theme_advanced_blockformats']);
unset($init['theme_advanced_styles']);
break;
}
// FILTRA LE PROPRIETA E CANCELLA CIO CHE NON E' STRICT
switch ($theme_name) {
case 'advanced':
$init['extended_valid_elements'] = 'a[href|name|title|onclick],';
$init['extended_valid_elements'] .= 'table[],';
$init['extended_valid_elements'] .= 'img[alt|class|height|name|onclick|ondblclick|
onkeydown|onkeypress|onkeyup|onmousedown|onmousemove|
onmouseout|onmouseover|onmouseup|src|style|title|width]';
$init['theme_advanced_buttons3_add_before'] = 'tablecontrols,separator';
$init['plugins'] = file_exists(drupal_get_path('module', 'tinymce'). '/tinymce/jscripts/tiny_mce/plugins/drupalimage') ? 'drupalimage,table,emotions,print' : 'table,emotions,print';
$init['theme_advanced_buttons3_add'] = 'drupalimage,emotions,separator,print';
break;
}
// Always return $init; !!
return $init;
}
?>

Ovviamente quello sopra è solo un esempio striminzito, copiato da un mio vecchio post.... attualmente non posso mandarti la versione aggiornata e rivista perchè non ho accesso ftp da casa al sito in questione.

P.S.
se decidi di adottare una soluzione simile, fammi sapre che, se desideri, potremmo condividere un elenco di $init['extended_valid_elements'] consentiti..... mano a mano che qualcuno ne aggiunge uno, lo posta. Così ci potremmo ritrovare un filtro abbastanza buono da usare per tutti i singoli pulsanti (tag) di tiny

Ciao
Gianni

luisasasi wrote:

In pratica ho tre errori di priorità 3 che non riesco a rimediare si riferiscono al calendario, modulo EVENT. Uno, il più importante, è il summary della tabella, due sono links adiacenti: dovrei mettere i pipe di separazione (<< | Agosto 2007 | >>)
Chiaro debbo mettere mano al modulo. Dove? Per me che non conosco il php è un problema: tento e ritento...
Ora, grazie alle vostre spiegazioni so che se metto mano al modulo, quando faccio aggiornamenti di sicurezza devo ricorreggere: pazienza, lo rifarò ogni volta. L'importante è riuscire ad orientarmi quando chiudo gli occhi e ascolto con lo screen.

Ho visto il sito, se non erro chiedi come aggiungere i simboli di pipe nel calendario del blocco.
Per una modifica del genere devi operare all'interno di event.module

<?php
function event_calendar_month($op, $stamp, $types = NULL, $terms = NULL) {
 ...
 case 'block':
   // create caption and navigation links
+ $caption = _event_nav($stamp, 'prev', 'block', $types, $terms) .' '. l('|'. t(gmdate('F', $stamp)) .' '. $year .'|', 'event/'. $year .'/'. $month .'/'. $day .'/month') .' '. _event_nav($stamp, 'next', 'block', $types, $terms);
   $callback = 'event_render_day_single';
   ...
}
?>

Quote:

Per una sezione particolare dove raccogliere "segnalazioni di accessibilità" ben venga, sarebbe un'ottima cosa. Sono disposta a raccogliere tutto in un tutorial da mettere a disposizione.

Sarebbe veramente utile :)

giannigiusti wrote:

A me risulta, da un convegno a cui partecipai 3 anni fa, che l'ente può autocertificarsi (come avviene nel 90% dei casi sia A, AA o AAA)...... poi, il fatto che si appoggi a qualcuno perchè il sito non è sviluppato in casa, quella è un'altra storia. Tutto sommato con l'autocertificazione non fai altro che dichiarare punto per punto, il rispetto delle singole richieste (linee guida) della Stanca. Se hai un link o qualcosa che dice che le autocertificazioni su A e AA NON son valide, potresti inviarlo così me lo leggo? (visto che non è proprio un dettaglio) :-)

Guarda, non ho sottomano nulla, ma prova a vedere ai link:

• http://www.diodati.org/
• http://www.webaccessibile.org/
• http://www.pubbliaccesso.gov.it/
• http://www.cnipa.gov.it/

che sicuramente ne sanno di più di me, in particolare alla pagina:
http://www.pubbliaccesso.gov.it/logo/index.php
dovrebbe esserci tutta la procedura, se ti interessa AA e AAA forse ti conviene contattarli, e se lo fai tienici informati ;)
A memoria mi pare che solo enti accreditati diano la possibilità di avere certificazioni AA e AAA (per la WAI-A sci si può autocertificare). Era nata anche una associazione no-profit che era riuscita aad accreditarsi dove una serie di volontari (la magior parte diversamente abili e una parte di programmatori) controllavano gratuitamente i siti che venivano segnalati. Quando mi informai il tutto era composto da una decina di persone e ricevevano decine di richieste al giorno e quindi non ci stavano dietro, di conseguenza potevi aspettare settimane se non mesi prima di avere una risposta, non so se la cosa poi abbi preso piede o sia stata abbandonata, fattostà che non ne ho saputo più nulla, quindi mi fa poco sperare...

EDIT: Al link qui sotto trovi info riguardo gli enti accreditati, a quanto pare esistono ancora le associazioni ONLUS, ma credo che comunque siano a pagamento, dovranno giustificare le spese, così a occhio tengono dei disabili stipendiati (svolgendo così anche una funzione sociale) e gli fanno visitare i siti in questione dando così l'ok per la validazione. http://www.cnipa.gov.it/site/it-IT/Attivit%c3%a0/Elenco_valutatori_acces...

giannigiusti wrote:

mavimo wrote:

Per quello che riguarda i requisiti di accessibilità della legge Stanca il problema non è tanto il generare codice XHTML Strict, quanto seguire [cut...].

Si tratta di seguire la linea guida, rispettando quei punti (per fare un sunto breve) ;-)

Già, solo che seguire quei punti è alquanto problematico, infatti a parte quelli chiari che fanno parte del codice prodotto (tag, attributi, entità, ..) tutti gli altri sono abbastanza soggiettivi; hai voglia di dire che un certo tipo di contrasto di colore va bene, o che il layout è fluido e anche aumentando le dimensioni dei font va tutto bene.. o che è facilmente utilizzabile da persone affette da parkinson perchè i pulsanti del menu sono sufficientemente ampi e distanziati in modo che non si possa sbagliare per errore...
Tanto per fare un esempio banale, quanti hanno una distanza tra i link cliccabili dei menu ALMENO 0.3em e con margine di 0.5em? Ben pochi nonostante sia uno dei prerequisiti per la certificazione WAI-AAA (e forse anche per la AA)

giannigiusti wrote:

mavimo wrote:

Per quanto riguarda al possibilità di creare una sezione apposita del forum ne parlerò con Psico e vediamo cosa dice, in ogni caso approvo in pieno ;)

Anche perchè, fin quando si tratta di seguire le linee guida, sin tutti buoni a leggere, il problema è poi applicare alcuni punti, su Drupal. Altro problema è capire alcuni punti "legali" della stanca e non solo quelli tecnici (mi sembra che ci sia un po' di caos, in generale sul web)

Bhè, il problema principale non è applicarli, ma capire esattamente cosa vogliono cosa che tuttora IMHO resta un mistero. Ci sono persone decisamente preparate e professionali che hanno contribuito a gettare le linee guida, nonché hanno contribuito a scrivere la legge (vedi Roberto Scano), che però i burocrati hanno pensato di rendere incomprensibili senza l'aiuto di un avvocato; In definitiva hanno trasformato un documento tecnico in un legge.. e secondo me chi deve capire cosa c'è scritto per metterlo in pratica ci ha perso :D

giangiusti wrote:

mavimo wrote:

Per giangiusti, hai pensato di usare un software per la conversioen del contenuto delle pagine in XHTMl strict e creare uno script per prelevare e reinserire i dati nel DB? ne esiste uno ottimo open source (momentaneamente mi sfugge il nome), che funziona veramente bene, l'avevo provato e anche passando i documenti di word esportati come HTML faceva una pulizia tremenda e dava codice pulito :D

Il problema è che il precedente sito si trovava su notes domino.... oltretutto una vecchia versione e non sapevo come recuperare le pagine sul suo DB. Sul sito di IBM, avevo trovato gli ODBC...... peccato che erano per versioni più aggiornate della mia. Comunque, facendo copia incolla e modificando a manina, son riuscito, insieme alla redazione del sito, a passare tutte le pagine e a correggerle quasi tutte.... col tempo poi aggiusteremo anche le ultime rimaste.

Ormai il sito è convertito..... ma mi mancano ancora alcune pagine di enti esterni a noi collegati. Che tu sappia, il software che mi accennavi, può prendere in entrata anche pagine da wget? stavo pensando "se imposto wget per scaricare le pagine a N livelli e queste le do in pasto a quel software, mi dovrei ritrovare pagine strict".... magari con link errati, ma per lo meno corrette dal punto di vista tecnico.

Si lo faceva, io l'avevo usato all'interno di uno scrpt bash per far validare un sito di un centinaio di pagine (statiche)... sai che proprio non ricordo il nome.. sto goglando ma non trovo nessun riferimento.. e non me lo sono sognato!! :D mi pareva si chiamasse tinivalidator o qualche cosa del genere... in pratica prendeva una pagina qualsiasi e la trasformava in un albero completo secondo le speficiche XHTML (ovviamente non faceva miracoli, per esempio per l'alt delle imagini scriveva "immagine nomefile", ma meglio che nulla :D )... un pò come fa FF prima di renderizzare la pagina, la trasforma in un XML completo e poi manda il tutto in pasto al motore grafico...

EDIT: trovato il progetto http://tidy.sourceforge.net/ cerca l'eseguibile compilato per la tua architettura e OS..

giangiusti wrote:

mavimo wrote:

Tanto per sapere per rendere TinyMCE che fornisce soo XHTML valido intendi che ahi abilitato solo alcuni pulsanti o che hai fatto qualche modifica al codice per ottenere risultati decenti?

TinyMCE, restituisce XHTML.... il problema è che non è STRICT.... però..... puoi impostare dei filtri sia a livello di tag, sia a livello di proprietà (senza variare il codice).... in questo modo, ho deciso io i tag consentiti e quelli "vietati", pur mantenedo la barra standard di tiny. In poche parole il redattore usa tinyMCE con tutti i pulsanti che voglio, ma quando mette un immagine, un link o quant'altro, le proprietà scritte al suo interno, saranno solo quelle permesse da me.... nel caso di immagini ad esempio, può smanettare quanto vuole, ma le proprietà restituite saranno solo: alt,class,height,name,src,style,title,width (questo è solo un esempio)

[CUT]

Ovviamente quello sopra è solo un esempio striminzito, copiato da un mio vecchio post.... attualmente non posso mandarti la versione aggiornata e rivista perchè non ho accesso ftp da casa al sito in questione.

Ok, per ora grazie, ho capito cosa intendevi, ma per esmepio le immagini devono avere OBBLIGATORIAMENTE l'attributo alt, e finora non ho trovato il modo di costringere l'utente a inserirlo, così come non posso obbligare a mettere degli accesskey ai link e cose del genere, mi sa ceh per quello l'unico modo è andare a ravanare nel JS, ci avevo provato, ma è al di fuori delle mie capacità/tempo a disposizione :D
Speravo di trovare qualche altro editor più customizzabile e sopratutto leggero, TinyMCE è un vero e proprio mattone, ma non avevo cavato fuori nulla (tra prodotti free), quindi resto in attesa che BUEditor prosegua con lo sviluppo :D

giangiusti wrote:

P.S.
se decidi di adottare una soluzione simile, fammi sapre che, se desideri, potremmo condividere un elenco di $init['extended_valid_elements'] consentiti..... mano a mano che qualcuno ne aggiunge uno, lo posta. Così ci potremmo ritrovare un filtro abbastanza buono da usare per tutti i singoli pulsanti (tag) di tiny.

Potrebbe essere una buona idea... prometto che appena (se mai riuscirò) avrò tempo mi dedicherò a fondo su questo, ma per ora proprio non se ne parla.. se però intanto vuoi cominciare tu ;)

mavimo wrote:

Guarda, non ho sottomano nulla, ma prova a vedere ai link:

• http://www.diodati.org/
• http://www.webaccessibile.org/
• http://www.pubbliaccesso.gov.it/
• http://www.cnipa.gov.it/

che sicuramente ne sanno di più di me, in particolare alla pagina:
http://www.pubbliaccesso.gov.it/logo/index.php
dovrebbe esserci tutta la procedura, se ti interessa AA e AAA forse ti conviene contattarli, e se lo fai tienici informati ;)

Per esporre il logo che attesta il superamento del requisito di accessibilità per il sito http://www.rescaldina.org ai sensi dell'art. 8 del DPR 1 marzo 2005, n. 75, possono farlo seguendo la modalità espresse dall'articolo 8 che riporto sotto:

Art. 8
(Modalità di utilizzo del logo da parte dei soggetti
di cui al comma 1, dell’articolo 3 della legge n. 4 del 2004)
1. Le amministrazioni pubbliche e comunque i soggetti di cui all'art. 3, comma 1, della legge n. 4 del 2004, che intendono utilizzare il logo sui siti e sui servizi forniti, provvedono autonomamente a valutare l'accessibilità sulla base delle regole tecniche definite con il decreto del Ministro per l'innovazione e le tecnologie, di cui all'articolo 11 della legge n. 4 del 2004; la valutazione positiva, previa segnalazione al Cnipa, consente l'utilizzo del logo.

Praticamente, ti puoi autocertificare, poi ti registri, invii l'autocertificazione (dichiarazione di conformità).
A quel punto, loro verificano. Se sei conforme sei autorizzato ad usare il logo..... a me sembra che sia così, da quel che si legge.
http://www.pubbliaccesso.gov.it/logo/index.php

Da quel che ho capito, l'ente certificatore funge solo da verifica della tua autocertificazione (o della certificazione di chi che sia). Poi, i costi (partecipazione alle spese) che ciò comporta non si capisce una mazza.

mavimo wrote:

hai voglia di dire che un certo tipo di contrasto di colore va bene

Sui colori, imo, non ci può esser errore, visto che viene calcolato in modo "matematico" (essendo una differenza che deve rimanere in un certo range)

mavimo wrote:

EDIT: trovato il progetto http://tidy.sourceforge.net/ cerca l'eseguibile compilato per la tua architettura e OS..

Grazie 1000

mavimo wrote:

Ok, per ora grazie, ho capito cosa intendevi, ma per esmepio le immagini devono avere OBBLIGATORIAMENTE l'attributo alt, e finora non ho trovato il modo di costringere l'utente a inserirlo, così come non posso obbligare a mettere degli accesskey ai link e cose del genere, mi sa ceh per quello l'unico modo è andare a ravanare nel JS, ci avevo provato, ma è al di fuori delle mie capacità/tempo a disposizione :D

Questo è il problema più grande dell'accessibilità..... chi butta dentro le pagine, spesso non sa una mazza di html e accessibiltà. Fortunatamente da noi la parte redazionale è gente sveglia.
Comunque, esiste un editor XHTML Strict che crea codice accessibile.... ma:
1) se non sbaglio è un activeX
2) è a pagamento
......in questo momento mi sfugge il nome

mavimo wrote:

Potrebbe essere una buona idea... prometto ceh appena (se mai riuscirò) avrò tempo mi dedichero fondo s questo, ma per ora proprio non se ne parla.. se però intanto vuoi cominiciare tu ;)

Volentieri.... anzi, appena passo il nuovo sito sul server di produzione, verifico anche se è possibile obbligare l'inserimento di tag con tiny (tanto mi serve anche a me ed è una cosa di cui non ho mai avuto bisogno, ma mai neppure ci avevo pensato.... semplicemente ho istruito la redazione a farlo)

Ciao
Gianni

Ho creato il forum per discutere di accessibilità e usabilità di Drupal, appena ho tempo cerco di spostare i topic nel form appropriato, per ora se c'è da discutere facciamo dall'altra parte ;)