Pensiero libero: Per un sofware di qualità

[MiChiamo.Diego]

Esempio brutale

Un cliente mi incarica di sviluppare un applicazione web in PHP utilizzando però XHTML 5.0, e mettiamo caso che non esiste nessun "Template Engine" per XHTML 5.0. Sorge dunque un problema. Come sviluppare professionalmente la mia applicazione non conoscendo a fondo XHTML 5.0 e non utilizzando nessun "Template Engine"? E inoltre non esistono elementi div, b, span ma bensi altri elementi! A questo quesito risponde affermativamente il DOM e posso procedere nel creare le classi necessarie (ovviamente dopo aver analizzato in dettaglio il mio problema)!

[MiChiamo.Diego]

Non mandiamo in off topic una discussione interessante, e inoltre non giochiamo sulle parole! Da poco tempo si affermata fortemente la OOP!

[MacApp]

Originariamente inviato da MiChiamo.Diego
Non mandiamo in off topic una discussione interessante, e inoltre non giochiamo sulle parole! Da poco tempo si affermata fortemente la OOP!

Se tu ci credi, contento te contenti tutti.

Ma ad esempio.. MacApp è stato rilasciato nel 1985.
http://en.wikipedia.org/wiki/MacApp

Certo, allora gli sviluppatori php neppure esistevano
;-)

[Darsch2501]

Io sinceramente ancora fatico un po' a "pensare in OOP", nel senso che non mi viene ancora naturale. In parte dipende dal fatto che fino ad ora ho sempre lavorato in posti in cui ero l'unico a sviluppare quella data applicazione, quindi non c'erano diversi "reparti" che ci mettevano le mani, e l'esigenza di mantenere i vari blocchi separati non l'ho mai sentita eccessivamente.
Poi attualmente lavoro principalmente ad un applicativo di tipo amministrativo, abbastanza complesso, ma che ho strutturato in un modo tale che mi risulta molto più comodo avere un'organizzazione di tipo procedurale delle varie funzioni disponibili (ognuna memorizzata in un file include esterno) piuttosto che una complessa rete di classi e sotto-classi. L'involucro esterno (che si occupa dei permessi, della sicurezza e della gestione degli utenti) e' a oggetti (molto basilari pero').
E' un miscuglio un po' strano, me ne rendo conto, ma mi trovo bene, soprattutto perche' il tutto genera un output xhtml molto ben organizzato e per andare a modificare la parte grafica basta mettere le mani sul CSS, non c'è bisogno di decifrare il mio codice. I template engine, infatti, non li trovo indispensabili... se si struttra bene l'output xhtml basta lavorare sui CSS (www.csszengarden.com insegna). Ovviamente dipende dall'applicazione... certo un CMS con i controfiocchi necessita sicuramente di un template engine, perche' i CSS sono sempre limitati a quello che gli mandi tu in output...

Comunque trovo il discorso di MiChiamo.Diego sostanzialmente giusto. "Pensare in OOP" quando si progetta un'applicativo è sicuramente una mossa azzeccata, soprattutto se si guarda in prospettiva futura. Dipende però dal tipo di progetto... non credo che l'affermazione "se e' OOP e' sicuramente meglio e piu' professionale" valga in assoluto. ^_^

[daniele_dll]

Originariamente inviato da Tobler
Si è centrato un argomento sul quale rifletto da diverse notti. Da un lato facendo come suggerito php "fa tutto", per evitare situazioni del tipo:

<h1><?php if(...) ... else ...?></h1>

che un po' mi fanno sentire nonprofessionale, dall'altro però che fine fa la parte di design html e la manutenibilità? E il designer che dovrà applicare stili immagini etc dovrà impararsi php per forza?
Non sono domande retoriche, sto cercando veramente una risposta!

Originariamente inviato da isAlreadyInUse
Scusa secondo te perche è sorta la necessita di avere linguaggi che permettessero di integrare codice html a codice del linguaggio di programmazione

questo non è "utilizzare un template engine" questo è buttare del codice php dentro l'html costringendo non solo il designer a conoscere il php perché lo deve spostare ove serve ma in aggiunta le modifiche grafiche sono una vera e propria croce!

Originariamente inviato da MiChiamo.Diego
E' comprensibile quello che dici, ma ormai il mondo girà molto velocemente e di conseguenza lo sviluppo di qualsiasi software deve essere rapido. Programmare ad oggetti rappresenta il nuovo modo per gestire tutte queste variabili con nuova complessità. La OOP permette di sviluppare un ottimo software, per dire professionale. Il concetto della OOP deve essere ben chiaro (altrimenti il discorso sfuma). Il DOM ci permette di ottenere un livello di astrazione in modo tale da non preoccuparci di cosa ci sia effettivamente alla base.

Esempio, guardate questo codice

<?xml version="1.0" encoding="urf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
 "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="it" lang="it">

Vi è un errore poco professionale, che rende l'applicazione quasi non gestibile perchè non si conosce realmente l'encoding da utilizzare. Utilizzando DOM questo non sarebbe mai capitato. (Crea software in poco tempo e di qualità).

embé? cosa c'entra il DOM con tutto ciò? lo inserisci a mano -.-

Non puoi decidere di UCCIDERE il webserver (lo sai vero che quell'estensione è abbastanza pesante e se la usi per una cosa del genere lo diventa ancora di più) perché ti stuffa o non vuoi controllare cosa scrivi ... perché ne più ne meno si tratta di questo

Senza considerare che l'esempio che hai fatto è poco sensato dato che l'encoding è possibile settarlo anche tramite header inviati al client (i meta tag sono spuntati dopo, come anche lo specificare la codifica nella testata)

La qualità del codice la ottieni:
- sfruttando una serie di automatizzazioni che ti permettono di testare l'affidabilità del codice, ad esempio PHPUnit
- utilizzando una serie di strumenti che ti permettano di controllare quello che realizzi, un esempio è la Web Developer Toolbar di firefox o l'omonima per Internet Explorer, poi c'è firebug, HTML Validator e cosi via
- la qualità l'ottieni utilizzando un repository del codice sorgente che ti permette di tenere traccia passo per passo di tutto quello che è successo sul codice e ti aiuta a mantenere le versioni, le roadmap, le release personalizzate e cosi via
- aumenti la qualità se sviluppi VERAMENTE OOP utilizzando i Design Pattern che servono (per esempio ridurre il più possibile l'uso di metodi/classi statiche, ridurre l'uso di variabili globali, invece di istanziare una classe base e poi settare i parametri di la creare una classe che estenda quella base e che riduca la duplicazione del codice [in questo modo metti tutto li dentro altrimenti lo devi mettere sempre fuori]
- aumenti la qualità se utilizzi Template Engine, MVC, ORM, DBAL e cosi via tanta altra roba

queste cose sono quelle che REALMENTE aumentano la qualità, il codice tuo diciamo che potrebbe rientrare in una sotto categoria dei template engine che, però, comportano al designer di IMPARARE non solo a programmare in php ma obbligano il designer a imparare l'html per bene perché altrimenti, dovendo scrivere codice php usando dom per descrivere le pagine, non ci capiscono più niente tra nodi padre, nodi figlio, elementi e cosi via

Originariamente inviato da MiChiamo.Diego
Esempio brutale

Un cliente mi incarica di sviluppare un applicazione web in PHP utilizzando però XHTML 5.0, e mettiamo caso che non esiste nessun "Template Engine" per XHTML 5.0. Sorge dunque un problema. Come sviluppare professionalmente la mia applicazione non conoscendo a fondo XHTML 5.0 e non utilizzando nessun "Template Engine"? E inoltre non esistono elementi div, b, span ma bensi altri elementi! A questo quesito risponde affermativamente il DOM e posso procedere nel creare le classi necessarie (ovviamente dopo aver analizzato in dettaglio il mio problema)!

ah beh, è estremamente semplice ... nel file del template engine (io ne ho scritto uno mio che prende dei file HTML con dentro dei pseudo commenti e li separa in un alberò in base all'innestamento dei vari blocchi di codice html identificati dai commenti) che contiene la parte iniziale dell'html ci inserisci l'apertura per l'xhtml 5 ... nulla di più semplice ... cosi come il mio anche gli altri.
E se lo vuoi automatizzare inserisci tra i vari tag della pagina html delle variabili che vengono sostituite con i contenuti in modo da lasciare sempre fisso che so la codifica UTF8 ma cambiare il linguaggio descrittivo a piacimento

[gianiaz]

Originariamente inviato da MiChiamo.Diego
Non mandiamo in off topic una discussione interessante, e inoltre non giochiamo sulle parole! Da poco tempo si affermata fortemente la OOP!

Il problema è che tu identifichi la programmazione OOP con l'utilizzo della classe DOM.

Non puoi arrivare qui e dire, chi programma a oggetti usa la classe DOM, invece chi usa un template engine sbaglia.

Inoltre la richiesta di ricreare un sito in XHTML 5 avverrà forse nel 2040, visto che siamo all'XHTML 1.1, spero sia stata una svista, altrimenti dubito ancora di più di quello che scrivi, e anche se fosse mi sembra inverosimile che mi arrivi una richiesta del genere prima che sia stato sviluppato un template engine (che se voglio mi posso fare pure io, visto che si tratta di sostituire con una regex un po' di variabili).

Sono sicuro che sei un ottimo programmatore, questa è un opinione personale, e so che quello che sto per scriveree non ti piacerà, ma al tuo secondo messaggio sul forum ti sei messo a dare lezioni, senza un minimo di apertura mentale, ti sono state portate da più persone delle obiezioni intelligenti, e l'unica cosa che hai risposto (semplificando molto) è :

Io so programmare a oggetti perchè uso la classe DOM.

Esistono diversi modi per fare una cosa, tutti più o meno validi, e una discussione intelligente porta a confrontare le idee:

- tu dici che la classe DOM permette di slegare l'interfaccia dal codice php
- ok, ti dico io, anche un template engine permette di farlo e mi permette di semplificare il codice.

Ora tocca a te rispondere con una buona obiezione, se non ce l'hai è inutile che continui a basare le tue risposte sul fatto che questa è programmazione a oggetti, perchè non c'entra nulla, sono 2 discorsi diversi, se vuoi elogiare la programmazione a oggetti fallo parlando di programmazione a oggeti, e non del paradigma MVC.

ciao

[MiChiamo.Diego]

Mediocre, stava scritto "Esempio brutale". Comunque indipendentemente dal DOM, la OOP è consigliabile per lo sviluppo di software di qualità. Offendere è sempre la cosa più facile!

[MiChiamo.Diego]

Ma infatti non sto dicendo che chi usa la classe Engine sbaglia. Questo non l'ho mai detto, ma probabilmente è molto facile rimanere delle proprie convinzioni e farsi "masti" (maestri di qualcosa). Non mi permetterei mai! e sottolineo mai!

Inoltre la richiesta di ricreare un sito in XHTML 5 avverrà forse nel 2040, visto che siamo all'XHTML 1.1, spero sia stata una svista, altrimenti dubito ancora di più di quello che scrivi, e anche se fosse mi sembra inverosimile che mi arrivi una richiesta del genere prima che sia stato sviluppato un template engine (che se voglio mi posso fare pure io, visto che si tratta di sostituire con una regex un po' di variabili).

Era da titolo un esempio brutale (tanto per darne l'idea).

Io so programmare a oggetti perchè uso la classe DOM

Non ho mai detto questo se ti rende piu felice nego di saper utilizzare il DOM, cosi non ti crea tanti problemi.

Stavo affrontando il problema su un altro punto di vista, ma visto che sei cosi ostinato pensala come vuoi, non sto in alcuno modo a criticare quello che tu pensi o il tuo modo di programmre. Effettivamente per la soluzione di un problema ci sono sempre più alternative non solo una. Se qualcuno ha la mette così piccola da pensare che io sto lanciando affermazioni, tenendo lezioni, affermando che il mio è assoluto o che sia il braccio destro di DIO si sta sbagliando. Quello di mentalità più stretta sei proprio tu.

[gianiaz]

abbandono la discussione

[daniele_dll]

Originariamente inviato da MiChiamo.Diego
.
.
.

beh, permettimi di dire che probabilmente stavi sottolineando le funzionalità offerte dal dom in maniera un pò eccessiva, o almeno a me è sembrato cosi, nel senso che, proprio come hai appena detto, per un problema ci sono possibilmente 100 soluzioni diverse che vanno a coprire 1000 aspetti diversi tra loro (performance, usabilità, curva di apprendimento, memoria consumata, complessità del codice, espandibilità e cosi via )