[PLUTO-devel] Ingenium, step 1

[Marco Marongiu]

Claudio Cattazzo ha scritto:
> On Thu, Jul 14, 2005 at 01:25:49AM +0200, Marco Marongiu wrote:
> [...]
> 
>>Nel documento finale in XML, ci sono degli errori che il parser ha
>>prontamente rilevato ma che non ho corretto:
> 
> 
> Non ho ben capito perché restano degli errori...
> Tra l'altro, ho visto che i vari file xps non sono particolarmente lunghi,
> vuoi dirmi che con così poco codice riesci già a gestire la gran parte dei
> tag del DTD?

Si :-D

>>Vi allego una tarball che sto per mettere anche su OGo. Spero possa
>>essere un buon punto di partenza per cominciare a lavorare su uno
>>stylesheet in XSL (oppure, se preferite, potremmo passare a XPathScript
>>e tanti saluti, ma questo preferisco che lo vediate voi).
> 
> 
> Io di XPathScript non so proprio nulla e, guardando un attimo i file che hai
> scritto, ho visto che ha una sintassi abbastanza diversa rispetto a XSL.

Se conosci Perl e un po` di XPath, sai gia` molto di XPathScript!

In estrema sintesi, XPathScript e` la "fusione" fra Perl e le
funzionalita` tipiche di XPath per manipolare i nodi. Se prendi i fogli
di stile che ci sono nella tarball che ho mandato noterai che:

* c'e` un foglio di stile principale, xpj.xps, che contiene lo scheletro
HTML della pagina che si andra` ad ottenere

* le parti di codice perl sono comprese fra pseudo-tag <% e %>, come
avviene in altri sistemi; le parti che servono a inserire direttamente
nella pagina il valore di un'espressione sono invece comprese fra i
pseudo-tag <%= e %> (p.e.: <title><%= $title %></title>)

* moduli esterni del foglio di stile sono importati con una sintassi
simile a quella dei server-side includes:

    <!--#include file="xpj/functions.xps"-->
    <!--#include file="xpj/templates.xps"-->

* in XPathScript e` possibile usare indifferentemente l'approccio
procedurale e quello "a template". Per esempio, la parte che genera
l'indice che compare in cima all'HTML e` essenzialmente procedurale:

      <div class="index">
      <%= dump_chapters_index( path => '/article/chapter',
                               base => 1 ) %>
      <%= dump_chapters_index( path => '/article/appendix',
                               base => 'A' ) %>
      <% if (findnodes('/article/biblio')) { %>
      <br><a href="#biblio">Bibliografia</a>
      <% } %>
      </div>

Viene chiamata la funzione dump_chapters_index (azz... doveva essere <%
e non <%=... da correggere!!!) con due parametri diversi che gli
indicano di quali sezioni deve creare l'indice. A sua volta, la funzione
dump_chapters_index e` fatta cosi':

      sub dump_chapters_index {
        my %parms = @_ ;

        croak "Node path missing" unless defined $parms{path} ;

        unless (defined $parms{base}) {
          carp "No base index, defaulting to 1" ;
          $parms{base} = 1 ;
        }

        my ($path,$base) = @parms{qw(path base)} ;

        my $chindex = $base ;
        foreach my $chapter (findnodes($path)) {
          my $chtitle = $chapter->findvalue('title/text()') ;
          my $label = $chindex ;
print qq(      <br><a href="#$label">$chindex. $chtitle</a>) ;

          if (my @sections = $chapter->findnodes('section')) {
print qq(      <ul>) ;
            my $secindex = 1 ;
            foreach my $section (@sections) {
              my $sectitle = $section->findvalue('title/text()') ;
              $label = "$chindex.$secindex" ;
print qq(        <li><a href="#$label">$label. $sectitle</a></li>) ;
              $secindex++ ;
            }
print qq(      </ul>) ;
          }
          $chindex++ ;
        }
      }

A parte l'indentazione barbara dovuta alle patch frettolose di ieri, il
funzinamento e` semplice: $chindex e` il contatore dei capitoli,
$secindex il contatore delle sezioni all'interno del capitolo. Per ogni
nodo <chapter> che viene trovato viene creata una label da mettere
nell'indice. Se il capitolo ha anche sezioni facciamo lo stesso lavoro
fino a esaurirle. A fine ciclo incrementiamo l'indice di capitolo e
ricominciamo il giro. Il risultato e` quello che vedete sulla pagina HTML.

* l'approccio "a template" viene invece applicato tramite la funzione
"apply_templates":

      <%= apply_templates('/article/chapter') %>
      <%= apply_templates('/article/appendix') %>
      <%= apply_templates('/article/biblio') %>

I template si definiscono, ovviamente, in termini di assegnazioni perl
ad una variabile predefinita, $t, che e` una reference ad un hash
multidimensionale. Possono essere semplici come:

      # <kw>
      $t->{kw}{pre}  = '<span class="keyword">' ;
      $t->{kw}{post} = '</span>' ;

oppure piu` complessi, eseguendo anche del processing elaborato:

      # Biographies
      $t->{bio}{testcode} = sub {
        my ($node,$t) = @_ ;

        my $pretag = qq(<p class="bio">) ;
        my $postag = '</p>' ;
        my $face = $node->findvalue('@face') ;

        if ($face) {
          $pretag .= qq(<img src="$face" align="left">) ;
          $postag = qq(<br clear="left">$postag) ;
        }

        $t->{pre}  = $pretag ;
        $t->{post} = $postag ;

        return 1 ;
      } ;


* in sostanza, e` possibile percorrere piu` volte e in diversi modi il
documento XML durante il processing per creare il documento finale.
Avevo provato a capire come ottenere lo stesso risultato con XSLT, ma mi
era sembrato molto macchinoso. Ma questa potrebbe essere tranquillamente
una mia deformazione mentale (molto Perl-oriented :-).

> Di XSL invece qualcosa so e non è difficile impararlo per semplici scopi,

...ma non e` detto che il processing di un documento XPJ sia un
"semplice scopo"...

> comunque il punto è che al momento, purtroppo, non ho tempo di dedicarmi
> alla creazione di un foglio di stile completo.

Uottebbaut Marcello?

> Come ho già detto, non conosco XPathScript, non so che vantaggi e svantaggi
> possa avere rispetto a XSL,

I principali:

* vantaggi: e` flessibile e potente almeno quanto Perl
* svantaggi: non e` uno standard, mentre XSL lo e`...

> ma di certo, data la situazione attuale del
> progetto, avere un foglio di stile in qualsiasi linguaggio quasi pronto già
> ora mi sembra un vantaggio non da poco.
> 
> Tu che ne pensi?

Che se vogliamo procedere nella politica dei piccoli passi, potremmo
cominciare con XPathScript ed elaborare una soluzione standard con piu`
calma. A questo punto pero` mi servirebbe un layout delle pagine su cui
definire il foglio di stile, e il CSS associato. Fate conto che entro
lunedi io partiro` per il mare e non avro` accesso alla rete; almeno per
il periodo 18-25 luglio saro` completamente fuori linea.

Credo inoltre che bisognerebbe spingere la parte di
creazione/adattamento di un editor, perche' vi posso assicurare che fare
la conversione a mano da HTML a XPJ, oltre a prendere molto tempo, e`
una gran rottura di scatole.

Boh, pensiamo ci un attimo e decidiamo come muoverci. Poi... muoviamoci
:-) Soprattutto, approfittiamo di questi mesi in cui anche il carico al
lavoro e` normalmente piu` basso, perche' una volta che arriveranno
settembre e ottobre torneremo tutti nelle sabbie mobili da cui stiamo
faticosamente uscendo in questo periodo di ferie.

Ciao!
--Marco