A volte ritornano... Re: [PLUTO-Journal] XPJ

[nicolafragale a libero.it]

 Marco Marongiu wrote:

>
>
> Claudio Cattazzo wrote:
>
>> Io ho scritto da zero un DTD XML
>
>
> ..cosa che avevo fatto anche io...
>
>> e un XSL che crea un Journal in XHTML.
>
>
> ..ma il mio era orientato all'articolo singolo. L'idea originaria era di avere
un "prodotto" che permettesse agli articolisti di editare in maniera visuale un
articolo (da qui l'originario post di Nicola su VEX), che poi sarebbe stato
convertito in N formati.
>
> Di quel progetto rimangono:
>
> * il mio DTD
> * un file XPJ di demo, che usa tutti i tag
> * un foglio di stile XPathScript che trasforma quell'articolo in HTML
>
>>> Che ne dite se ci dessimo degli appuntamenti fissi, in modo che si possa
condurre il progetto in porto, almeno come alfa?
>>
>>
>>
>> Prima bisogna decidere bene cosa fare.
>
>
> Sono d'accordo.
>
> Decidiamolo :-) E vale la regola: "Chi propone, fa; chi fa, decide".
>
>> Tempo fa ho chiesto su questa lista
>> se c'era qualcuno che se ne intendeva di XSL,
>
>
> ..e io non potevo risponderti. Io ho sempre usato XPathScript perche' non ho
mai avuto tempo e modo di impararmi XSL, mentre gia` conoscevo Perl e AxKit.
>
>> perché la mia idea era quella
>> di creare un unico file XML che contenesse tutto il Journal e da lì che
>> l'XSL spezzasse il file nei vari articoli e producesse la versione XHTML e
>> quella PDF.
>
>
> Ok. Apriamo la discussione, posto che la regola per parteciparvi e` quella
sopra (altrimenti ci impantaniamo di nuovo e questa volta veramente non ci
muoviamo piu`).
>
> Punto primo, credo che la questione dell'editor visuale sia stata troppo
"bloccante" per il progetto, e che per il momento vada messa in secondo piano:
costruiamo un sistema, vediamo se e come funziona. Di come fare a buttargli
dentro i contenuti avremo tempo di discutere e di risolvere.
>
> Secondo me e` meglio partire dagli articoli singoli, in modo che ogni
articolista possa (un giorno) postare il suo senza dover avere in mano tutto il
giornale. Prevedere quindi un DTD per i singoli articoli, e un DTD "maggiore"
che includa le definizioni dell'articolo al suo interno. In pratica:
>
> <article>...bla...bla...</article> sara` definito dal DTD X
>
> <journal><meta>...informazioni su questo
numero...</meta><article>....</article><article>...</article>...</journal> sara`
definito dal DTD Y, con il contenuto dei tag <article> definito dal DTD X.
>
> Non so se mi sono spiegato :-\
>
> Che ne pensi/ate?

Ciao

io suggerisco di seguire un approccio a la Ingegneria del Software. Cioè
stabiliamo prima, e nel modo più preciso possibile le nostre necessità, passiamo
poi alla progettazione del sistema e infine iniziamo a scrivere il codice.

Una volta definite e formalizzate le nostre esigenze in un documanto di
specifica dei requisiti (scopo del progetto, tipo di tag da supportare, formati
in cui esportare, editor visuali o meno, tutto quello che dalla discussione
risulta essere utile, ecc), passiamo alla progettazione (per chi li conosce,
diagrammi UML per: Casi d'uso, Diagrammi delle Classi, Diagrammi di Sequenza,
ecc...). Apriamo su Pluto Devel una pagina ufficiale del progetto, pubblichiamo
questi documenti (che saranno la nostra guida) e iniziamo a scrivere il core del
codice. Chi decidesse di aiutarci nella realizzazione del progetto, non dovrebbe
far altro che seguire i documenti tecnici e auitare per quello che può/vuole
(test del codice prodotto, scrittura della documentazione, debugging, ecc).
Questa a grandi linee è la via che attualmente l'ingegneria del software
prescrive per la realizzazione di sistemi software di dimensioni non banali, e
il nostro ad occhio e croce lo è. I vantaggi principali di questo approccio sono
relativi ad una più semplice espandibilità e manutenzione, ad un codice più
pulito e coerente, meno bug dovuti ad incongruenze nel progetto (non si inizia a
scrivere codice da modificare più e più volte a causa di valutazioni scorrette) ecc.

Per quel che riguarda i DTD scritti a suo tempo da Marco, secondo me vanno
utilizzati tutti. Io non conosco XPathScript ma un altro dei vantaggi
dell'approccio che propongo è nel fatto che ognuno di noi si occuperebbe della
parte che meglio conosce, i vari moduli (DTD, editor, convertitori, fogli di
stile, ecc) sarebbero più o meno indipendenti l'uno dall'altro, e il temporaneo
rallentamento di uno non causerebbe molti danni agli altri.

Ho allegato alcuni diagrammi e le specifiche di un sistema software
"Fantacalcio" che, con il mio gruppo, ho preparato per l'esame di Ing. del
software, in modo che tutti possano farsi un'idea della cosa.
Ad es. sono d'accordo con Marco sull'uso di DTD diversi, per i singoli
articolisti e per l'intero Journal. Se accettata quesa diventerebbe una
specifica (un vincolo da rispettare) da inserire nel documento di specifica dei
requisiti. Dal documento di specifica dopo alcuni passaggi (scrittura degli
scenari) si giunge ai diagrammi dei casi d'uso (se vogliamo una rappresentazione
grafica delle specifiche, descrive le funzionalità che il sistema (o parti del
sistem) offre e i modi in cui l'utente del sistema o altre parti del sistema
possono utilizzare le funzionalità offerte). I diagrammi delle classi
visualizzano gli oggetti che realizzano il sistema. I diagrammi di sequenza
mostrano come i vari oggetti comunicano tra di loro per la realizzazione di uno
specifico compito. Passare dai diagrammi di sequenza al codice diventa poi
abbastanza semplice.

Tutto il lavoro da fare, che a prima vista sembrerebbe inutile, diventa invece
prezioso per l'effettiva creazione del software. Non è necessario essere ferrati
in ingegneria del software per discutere delle specifiche del software e per
scrivere gli scenari (i passi da seguire per realizzare un obiettivo). Per i
diagrammi delle classi chi ha un po di esperienza di programmazione ad oggetti
non dovrebbe trovarvi alcuna difficoltà. La realizzazione del nucleo del
progetto dovrebbe essere svincolata dall'interfaccia grafica, che sarebbe
l'ultimo tassello da realizzare.

Nicola

P.S.
i diagrammi allegati sono in svg (usate inkscape o un programma simile per
visualizzarli)

>
> Ciao
> --bronto
>




____________________________________________________________
Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega. E poi hai l'Adsl senza limiti a meno di 1 euro al giorno. 
Abbonati subito senza costi di attivazione su http://www.libero.it