Newsgroup: it.comp.lang.perl
Titolo: Gestione dello stato

<AVVISO> L' email presente nella intestazione del messaggio e' falso
(per evitare spam). Se volete contattarmi via email l' indirizzo è
inmodis at (chiocciola) tiscalinet punto it. </AVVISO>
Vorrei sapere se qualcuno di voi sa dirmi se esiste un modulo che
faccia parte della distribuzione Activestate (e quindi disponibile su
ambienti host condiviso sotto win) che mi consenta di facilitare la
gestione dello stato in una applicazione CGI implementando un
meccanismo di tipo Application e Session simile a quanto disponibile
in ASP
L' alternativa più immediata che vedo è: 
-cookie sul client con un digest MD5 della stringa ottenuta
concatenando IP del client con il tempo di chiamata;
-memorizzazione del digest su una tabella di database oppure su file
di testo in cui vado a scrivere coppie del tipo: nome=valore
Mi piacerebbe un meccanismo più semplice e immediato, se non dico
eresie, Inoltre non mi piace tutto questo movimento su disco ...
Ciao

 wrote in message
news:3d85936a...@news.tiscalinet.it...

Se ti riferisci a qualcosa di analogo a CGI::Application e CGI::Sessions, io
ho trovato CGI::Panel su CPAN, e forse è quello che cerchi. Se ci fai delle
prove, posta qui le tue impressioni, perché io ho solo letto la poverissima
documentazione e non ho nemmeno capito bene a cosa potrebbe veramente
servire (a parte a fare uno shopping basket).
http://search.cpan.org/author/RSYMES/CGI-Panel-0.91/lib/CGI/Panel.pm
ciao
dd

 
Se non vuoi utilizzare framework pre-esistenti recentemente ho messo su CPAN 
un modulo (Apache/mod_perl) Apache::SessionManager 
(
http://www.cpan.org/modules/by-module/Apache/Apache-SessionManager-0.02.tar.gz
)
che fa proprio questo in maniera automatica: assegna un ID di sessione 
utilizzando i cookies (o l'URL rewriting) per passarlo al client.
Poi tramite varie API memorizzi e prendi dalla sessione ciò che ti serve (non
solo coppie nome=valore ma anche cose più complesse come hash, array ,ecc.)
Come framework per per la memorizazzione di dati persistenti viene utilizzato
Apache::Session che consente di scegliere differenti data storage: file system,
memoria, Database, DB file , ecc.
Apache::SessionManager richiede Apache e mod_perl e Apache::Session, 
ma l'applicazione non deve essere necessariamente scritta sotto mod_perl (cioè
può essere anche un CGI standard)
Per soluzioni mod_perl-less guarda anche CGI::Session.
	- Enrico

 - Enrico
Ma se ho capito bene, il tipo chiede un metodo senza ricorrere
all'installazione di altri moduli,
in quanto chiede specificatamente: "se esiste un modulo che
faccia parte della distribuzione Activestate".
Che io sappia non c'è nulla di utile allo scopo, a meno di non usare cookies
e file temporanei vari.
Proprio per questo motivo, l'ultimo mio lavoro l'ho fatto in ASP VBScript
(trattasi di un carrello della spesa).
Ciao,
Guido.

(trattasi di un carrello della spesa).
... ed è esattamente quello che mi sta disturbando non poco.  Avere a
disposizione tutto quello che da il perl e non avere una gestione
trasparente dello stato per una applicazione CGI è decisamente
frustrante.
Daniele

> Daniele
Ora che ti sei firmato, il "tipo" finalmente ha un nome :-)
Mica ti sarai offeso se ti ho trattato da "anonimo" ??
Cmq il problema è questo: finché si tratta di semplici moduli *.pm li puoi
anche usare senza che siano installati; il fatto è quando si tratta di
moduli che richiedono la presenza di dll e cose simili, se non sono
installati non li puoi usare.
L'uso delle sessioni ha a che fare con la ram del server, quindi con il
daemon http in sé, e non è una cosa da poco. Su un server microsoft, lo sai,
basta fare cose del genere:
session("nomevariabile") = valore
e resta in memoria (ram) finché non viene chiusa la sessione (ovvero il
browser).
in effetti funziona cosi':
1. prima connessione al sito -> IP "nuovo" -> Cookie con l'id di sessione
2. il browser viene chiuso
3. il browser viene riaperto e ci si ricollega allo stesso sito di prima ->
Stesso IP di prima ma senza cookie -> nuovo cookie (nuova sessione)
Si potrebbe fare una cosa del genere "simulando" questo funzionamento.. ma
c'è da programmare, programmare, programmare.... programmare :-)
Ciao tipo!

 wrote in message
news:am5lij$ibr$1...@lacerta.tiscalinet.it...

FORSE ti sei perso CGI::Session dove il "programmare, programmare,
programmare.... programmare " è già fatto egregiamente da tal Sherzod
Ruzmetov!!!!
http://search.cpan.org/author/SHERZODR/CGI-Session-2.94/doc/Session.pod
dd

Ciao tipo!
Ciao ZioKiller


Questo č MOLTO interessante.
Ho verificato su 
http://aspn.activestate.com/ASPN/Modules/Perl/dist_html?dist_id=11032
per chi interessa, ed il modulo č effettivamente disponibile (anche se
non nella installazione nativa) sul port Activestate.
Grazie!

 (trattasi di un carrello della spesa).
Che usa i cookies... Inoltre in MS ASP nelle sessioni puoi salvare solo
scalari... :-)
   - Enrico
--------------------------------
Inviato via 
http://usenet.libero.it

 frustrante.
Come detto nei post precedenti ci sono moduli che gią lo fanno
ma che non fanno parte della distribuzione standard del Perl.
Inoltre ricordati che puoi usarli senza doverli farteli installare nelle
directory standard ma mettendoli nella semplicemente tua home
e aggiungendo nei tuoi script:
   use lib '/path/to/your/home';
(chiaramente se sono moduli del tipo CGI::xxx devi anche ricrearti
le sottodirectories)



Mhhh... senza rienventare la ruota ci sono già:
CGI::Session -> per applicazioni CGI senza supporto mod_perl
Apache::SessionManager -> per applicazioni CGI con supporto mod_perl e/o
moduli Apache scritti in Perl



A questo proposito che spero possa essere utile a tutti il seguente
approfondimento.
CGI::Session nasce come front-end ad Apache::Session (che a
dispetto del namespace non è assolutamente legato ad Apache potendo
essere utilizzato al di fuori di applicazioni web).
Successivamente, mantenendone l'idea base, e cioè l'interfaccia tie(),
ne è diventato indipendente reimplementandone in parte alcune features.
Tuttavia:
- I data storage attualmente disponibili sono solo: file system, MySQL e
DB_file
- I meccanismi di locking. CGI::Session::File usa la flock motivo
per cui funziona solo su Windows 2000 (o XP che ha lo stesso kernel).
Inoltre non è documentato se e come bypassare il locking.
CGI::Session::MySQL locka addirittura la tabella.
- non ci sono politiche di scadenza delle sessioni (se non nell'attributo
expires del cookie).
- lettura e settaggio del cookie (o del path_info) sono a carico del
programmatore.
Apache::SessionManager è un modulo che si avvantaggia della potenza
del mod_perl per fare in maniera trasparente alcune cose che
altrimenti nella programmazione CGI::Session è necessario ripetere
ogni volta. E cioè:
- settaggio del cookie (o riscrittura dell'URL) con l'ID id sessione
- lettura dell'ID di sessione dal cookie (o URL) e ripristino della sessione
- controllo della scadenza della sessione sia in termini di inattività
utente
che come tempo globale di durata sessione ed eventualmente creazione di
una nuova.
- datastore (file system, DB_file, MySQL, Oracle, Postgres, SyBase, RAM,
PHP-like) e meccanismi di locking ereditati direttamente da Apache::Session
Facciamo un esempio. Con CGI::Session per far partire una
nuova sessione bisogna (all'inizio di ogni script) scrivere il
seguente codice:
        use constant SESSION_COOKIE => "MY_SITE_SID";
        use CGI::Session::File;
        use CGI;
        my $cgi = new CGI;
        my $sid = $cgi->cookie(SESSION_COOKIE) || undef;
        my $session = new CGI::Session::File($sid,
            {
                Directory => "/tmp/sessions"
            });
        # invio il cookie al client con l'ID di sessione,
        my $cookie = $cgi->cookie(-name => SESSION_COOKIE,
                                     -value => $session->id,
                                     -expires=> "+1M");
        print $cgi->header(-cookie=>$cookie);
previo controllare che non ce ne sia una esistente e/o che
non sia scaduta.
Riprendo poi la sessione con il seguente codice:
        use CGI::Session::File;
        use CGI;
        $cgi = new CGI;
        $sid = $cgi->cookie("SID") || $cgi->param("sid") || undef;
        $session = new CGI::Session::File($sid,
                    { Directory => "/tmp" });
        # Let's update the session id (da documentazioe CGI::Session)
        $sid = $session->id;
        # Salvo un valore nella sessione
        my $f_name = $cgi->param( "f_name" );
        $session->param( "f_name", $f_name );
        # Prendo un valore dalla sessione
        $f_name = $session->param( "f_name" );
Con Apache::SessionManager ho il semplicemente il seguente codice:
use Apache;
use Apache::SessionManager ();
# prende la sessione
my $session = Apache::SessionManager::get_session(Apache->request);
#leggo un valore di sessione
print $session{'key'};
#salvo un valore nella sessione
$session{'key'} = "some value";
Non dovendomi preoccupare di settare/leggere cookie o mettere
l'ID di sessione nell'URL, controllare la scadenza della sessione, ecc.
Chiaramente devo configurare Apache (una volta per tutte) per
impostare i parametri di sessione (nome, politiche di scadenza,
datastore, ecc) con direttive in httpd.conf quali ad esempio:
   PerlModule Apache::SessionManager
   PerlTransHandler Apache::SessionManager
   PerlSetVar SessionManagerTracking On
   PerlSetVar SessionManagerExpire 3600
   PerlSetVar SessionManagerInactivity 900
   PerlSetVar SessionManagerStore File
   PerlSetVar SessionManagerStoreArgs "Directory => /tmp/apache_sessions"
La conclusione _non_ è certamente un'apologia del mio modulo
Apache::SessionManager, ci mancherebbe!!!! Anzi ogni critica/commento
sono i benvenuti!
Invece:
1. [OT] L'utilizzo dell'accoppiata Apache/mod_perl per lo sviluppo di web
application
dalle prestazione e caratteristiche nemmeno paragonabili a quelle ottenute
con script CGI.
2. L'utilizzo di Apache::Session come meccanismo per la memorizzazione
persistente di dati arbitrari su differenti datastore (in quanto più
flessibile e completo
di CGI::Session) nel caso tu voglia implementare una tua gestione delle
sessioni.
3. Non ultimo la valutazione dell'adozione di framework di sviluppo che già
hanno
tutto questo (Apache::ASP o l'equivalente ActiveState PerlScript per IIS),
anche
se mi sembra che il tuo ISP non lo supporti.


condividere anche le sessioni PHP
...io qui parlavo di come funziona il daemon MS :-)
Insomma, sappiamo tutti che Perl è un linguaggio che non ha fine, proprio
grazie alla sua scalabilità, espandibilità, portabilità ecc...
ma quando non si possono usare i moduli, bisogna per forza "attaccarsi" a
delle routine di fortuna.
Grazie Larry che hai inventato il Perl, grazie Aldo Calpini che hai scritto
Win32::GUI
Il programma di gestione telemarketing che sto facendo sta venendo proprio
bene :-)
Qualcuno si accorgerà mai che è stato scritto in Perl ?? :-))
(fin'ora l'unica persona che l'ha visto mi ha detto: "ah bravo, finalmente
ti sei deciso ad imparare Visual Basic!!" e io gli ho risposto: "Ma
vaff...!" heheheh)
Guido.

 delle routine di fortuna.
Ritorno su quel 'non si possono usare i moduli'. In generale infatti
non è necessario averli installati nelle directory di sistema ma possono
essere installati anche in altre directory il cui accesso non prevede
privilegi di root/administrator.
    - Enrico