[TYPO3-UG Italy] libro ExtBase / Fluid in ... INGLESE!

Tonix (Antonio Nati) tonix at interazioni.it
Tue Nov 23 19:55:16 CET 2010


Il 23/11/2010 18:32, Ivano Luberti ha scritto:
> Interessante......magari se motivi un po' le cose che dici.
> Te lo dico da ignorante del nuovo ambiente, non perche' pensi che tu
> dica cose sbagliate
>

E' difficile dare una risposta articolata ed esaustiva ma comunque breve.

Premetto che il modello di sviluppo del webmaster, mezzo grafico e mezzo 
programmatore, non mi interessa.
Mi interessa il grafico professionista diplomato (cinque anni, non i tre 
mesi della regione), e lo sviluppatore professionista (che prima di PHP 
la lavorato molto con C, o C++ o Java o comparabili), e sa fare inoltre 
analisi pura.

Scusa inoltre la negatività generale, ma io vengo da ambienti di 
sviluppo di grosse aziende, e sono abituato a vedere i prodotti 
migliorare, mentre su TYPO3 vedo un declino costante.

*Lavoro di gruppo.
*La cosa principale che mi aveva convinto di typo3 era la separazione 
tra grafica e codice, portata a livelli notevoli.
Prendi un grafico professionista, gli dai due o tre indicazioni su come 
"marcarti" delle aree, poi prendi il suo lavoro e lo usi così com'è.
Il grafico decide di cambiare il CSS o qualche parte HTML? Bene, lo fa, 
lo carica, e senza fare nulla, la pelle del sito è cambiata (al massimo 
svuoti la cache).
Lo stesso vale per le estensioni. Prendi i template HTML originali, li 
passi al grafico, li sostituisce, ed il gioco è fatto.
Così grafico e  sviluppatore possono condividere un'analisi e lavorare 
al massimo delle proprie possibilità.
Ognuno può cambiare quello che vuole nel proprio settore, senza 
disturbare il lavoro dell'altro (se non cambia l'analisi, ovviamente).

Ora, con extbase, il grafico lavora per un risultato html che sarà 
inutile, perché la pagina sarò costruita con un linguaggio inventato 
dallo sviluppatore. Quindi il grafico non vedrà il risultato del suo 
lavoro, perché sarà smontato, e nessuna sostituzione/cambiamento di 
grafica sarà più trasparente ed immediata come lo era prima.
Da WYSIWYG a You Don't See What You Get

*Modularità
*Il modo di funzionamento di constants e setup permette una notevole 
personalizzazione dei siti, influenzando funzionamenti, presentazione e 
quant'altro possibile in maniera molto semplice ed efficace.
Ti metti a tavolino, studi come i rami del sito devono variare, e 
tramite le possibilità offerte ci riesci molto agevolmente.
Puoi progettare tre rami completamente diversi, all'apparenza, tra loro, 
mentre invece le differenze stanno solamente nelle definizioni in 
constants, e nei template e CSS grafici.

Mi aspettavo che questa modularità migliorasse, gestendo, oltre alle 
pagine HTML, anche AJAX, XML e SOAP.
Ora, questo è possibile anche ora, ma come pezza, non come struttura. Ci 
voleva poco per metterli nella struttura, ma lo sviluppo ha deciso di 
buttare via  quello che c'è (che favorisce l'analisi) a favore del 
modello discutibile sopra descritto (che favorisce lo sviluppo mordi e 
fuggi).

*Teoria.
*DDD significa imparare il linguaggio del cliente, imparare i suoi 
problemi, realizzare presentazioni/documenti/analisi esclusivamente 
basati sul linguaggio del cliente, perché quello è il dominio di 
competenza, ed è con quel linguaggio che vanno affrontate e risolte le 
problematiche.
I problemi del dominio del cliente vanno poi trasferiti, in altro modo, 
nella realizzazione.
La realizzazione deve produrre delle interfacce che parlino il 
linguaggio del cliente, e deve usare le migliori (o più opportune) 
metodologie informatiche per la realizzazione.
E' possibile realizzare progetti che nelle interfacce sono sintonizzati 
al 100% col cliente, ma nelle "cose" interne seguono logiche 
completamente diverse. In ogni caso avranno metodologie, librerie, 
oggetti e stratificazione costanti e usabili da ogni informatico di pari 
livello.
Scrivere un progetto, nella parte di realizzazione, basato su un 
linguaggio creato per il cliente, non ha nessun senso, né logico né 
pratico, perché sarà lontano dalle migliori realizzazioni possibili dal 
punto di vista informatico, e oltre le interfacce non interesserà nessuno.
Addirittura si potrebbe creare un bel presupposto di inusabilità, perché 
ogni linguaggio sarà specifico solo per quel cliente, poco portabile in 
altre situazioni, e poco capibile da altri informatici.
Ora, uno sviluppo che va in questa direzione, non mi interessa. E degli 
sviluppatori, come quelli TYPO3, che vanno in questa falsa direzione, 
falsificando conoscenze e crediti DDD, vanno mollati subito.

*Sicurezza.
*Vuoi mettere un captcha nel login? Non lo puoi fare.
Vuoi mettere una specifica pagina sotto una ulteriore richiesta di 
password? Non lo puoi fare.
Vuoi usare tre autenticazioni diverse (folder, LDAP,MySQL), e decidere 
quale autenticazione ciascun ramo usa, tramite specifiche e non 
eludibili pagine specifiche di login? Non lo puoi fare.
Prima qualcosa di questi esempi era possibile, ma ora lo sviluppo ha 
deciso che la semplicità di realizzazione debba avere la meglio sulla 
sicurezza.

*BE Inutile
*Il BE è utile solo per un professionista o un utente finale esperto, 
per un utente finale normale è inusabile.
Un progetto serio deve riscriversi nel FE una decente gestione 
amministrativa.
E' inutile spendere energie per potenziare il BE, tanto vale potenziare 
altre aree.

*Documentazione
*Troppa, anzi inesistente. Scusa il gioco di parole. Ci sono tonnellate 
di documentazione inutile, e manca qualsiasi documento architetturale o 
di sintesi. La mailing list inglese è deprimente, di bassissimo livello 
(ma purtroppo questo sta accadendo un pò dovunque ultimamente).
E' come se ad uno che vuole studiare l'italiano tu regalassi gli elenchi 
telefonici di tutta Italia.
Sarà impressionato, poi quando capisce li butta nel cassonetto.
Questa cosa è stata detta e ridetta centinaia di volte, ma il modello 
rimasto è sempre quello.

Scusa la prolissità, spero di essere stato almeno chiaro.

Ciao,

Tonino




> Il 23/11/2010 18.08, Tonix (Antonio Nati) ha scritto:
>> Il 23/11/2010 17:56, Stefano Cecere ha scritto:
>>> On Tue, 23 Nov 2010 16:34:11 +0100, Tonix (Antonio Nati)
>>> <tonix at interazioni.it>  wrote:
>>>
>>>> Stefano, flow è la più grossa bufala degli ultimi trent'anni.
>>> esagerato, dai, Tonix!
>>>
>>> a parte che qui si parla di Extbase + Fluid (e non di FLOW3, che
>>> vedremo fra un paio d'anni come sarà :)
>>>
>>> con la 4.5 ci sarà un importante upgrade di queste componenti, e le
>>> principali estensioni di TYPO3 (compresa una nuova ttNews) sono in
>>> via di sviluppo con extbase/fluid
>>>
>> Ne riparleremo tra qualche anno.
>> Io sto trovando grossissimi passi indietro su analisi complesse,
>> integrazione trasparente ed immediata tra template e codice... La
>> sicurezza è peggiorata e sta diventando un colabrodo. Se devi fare un
>> sito sicuro al 100% non puoi usare typo3.
>>
>> Sto sviluppando un grosso progetto su TYPO3, ma sarà l'ultimo, vado a
>> cercare altri prodotti.
>>
>> Ciao,
>>
>> Tonino
>>
>>
>>
>>> da quanto ho visto e testato c'è solo da ringraziare che esistano
>>>
>>> benvengano cmq critiche, suggerimenti e.. patch! :)
>>>
>>>
>>> ____    ___   __  _ ______________________
>>>
>>>    Stefano Cecere
>>>    KRUR.com - creative culture
>>> _______________________________________________
>>> TYPO3-UG-Italy mailing list
>>> TYPO3-UG-Italy at lists.typo3.org
>>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-ug-italy
>>>
>>


-- 
------------------------------------------------------------
         Inter at zioni            Interazioni di Antonio Nati
    http://www.interazioni.it      tonix at interazioni.it
------------------------------------------------------------



More information about the TYPO3-UG-Italy mailing list