[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