domenica 11 gennaio 2009
Il capitolo 12 affronta l’accesso ai dati ed i web services (sia SOAP style che REST).
I post precedenti sono: ASP.NET, system administration, WPF, protocolli e metaprogrammazione, testing, proprietà, dialog e Visual Studio, first class functions e xml, applicazioni e design pattern, oggetti .NET e IronPython, introduzione a Python, introduzione al libro e il preambolo.
L’esempio sviluppato dal libro in questo capitolo sfrutta ADO.NET, il database opensource PostgreSQL e il data provider Npgsql.
Personalmente mi sento di consigliarvi PostgreSQL che non ha nulla da invidiare a SQL Server e se lavorate con GIS è decisamente una figata. Quì dove lavoor io lo usiamo felicemente per applicazioni di produzione (usiamo anche SQL Server 2000, SQL Server 2005, SQLite e credo anche MySQL).
L’esempio è, prevedibilmente, un programma che sfrutta il provider per fare query, usare bind variables, transazioni e sfruttare i data adapters.
La parte sui web services invece comincia mostrando un esempio che consuma un feed Atom per poi buttarsi sul consumo di un servizio SOAP, MathService.
Sfrutta tool come wsdl.exe per creare una dll proxy del servizio remoto e la usa da Python normalmente:
>>> import clr
>>> clr.AddReference('MathService.dll')
>>> from MathService import MathService
>>> service = MathService()
>>> service.Add(3, 4)
7.0
Data la dinamicità di Python i proxy possono essere creati anche a runtime, ovviamente. Purtroppo però, dato che IronPython non supporta direttamente gli attributi, non è possibile creare un webservice SOAP.
Fortuna vuole che per REST e HTTP le cose siano più semplici. L’autore a questo punto sviluppa un intero servizio REST in IronPython per gestire delle note (composte da titolo, corpo e id). Sostanzialmente oltre ai vari verbi HTTP fa uso di WebRequest, HttpListener, HttpUtility e un po’ di XML.
Una delle applicazioni che abbiamo sviluppato è una web application che espone anche un REST web service consumabile in vari linguaggi in maniera molto intuitiva. Purtroppo, secondo la mia esperienza, devo dare ragione a chi si lamenta della poca interoperabilità di SOAP tra vari ambienti. Mi è capitato di sputare parecchio sangue per interfacciarmi a web service esposti da Java che si comportano in modo diverso da quelli SOAP esposti da .NET (direttamente da SQL Server).
Il capitolo 11 comincia con una introduzione ad ASP.NET per poi buttarsi nello sviluppo di un clone web dell’applicazione MultiDoc realizzata precedentemente sul framework Windows.Forms.
I post precedenti sono: system administration, WPF, protocolli e metaprogrammazione, testing, proprietà, dialog e Visual Studio, first class functions e xml, applicazioni e design pattern, oggetti .NET e IronPython, introduzione a Python, introduzione al libro e il preambolo.
Per usare IronPython con ASP.NET oltre Visual Web Developer Express o Visual Studio si ha bisogno anche di IronPython for ASP.NET disponibile sia per la versione classica (quella usata dal libro) che per la versione MVC di ASP.NET. I dettagli dell’integrazioen sono specificati in un apposito whitepaper: The New Dynamic Language Extensibility Model for ASP.NET.
La cosa interessante è che IronPython è perfettamente integrato nel debugger visuale, per cui non si perde niente in questa fase.
Dopo aver installato il pacchetto di integrazione il libro comincia a sviluppare l’applicazione MultiDoc sfruttando alcune feature, il Global.py, per avere a disposizione tutta la libreria standard di Python da ASP.NET.
Il primo esempio è sostanzialmente un excursus su controlli quali il Repeater ed eventi come Page_Load e Page_Prender.
Dopo aver introdotto il concetto di viewstate fa notare come la personalizzazione della serializzazione dello stesso non sia disponibile direttamente da IronPython. In pratica SaveViewState e LoadViewState non sono direttamente accessibili, alché usa una classe C# (evviva l’ambiente multi linguaggio!) per ovviare al problema.
In seguito, necessitando di serializzare oggetti Python, evidenzia come questi ultimi non siano direttamente gestibili dalla machinery del viewstate. Il trucco sta nell’usare la classe System.Web.UI.Pair e la serializzazione Python (pickling) abbinando i due nello stato del viewstate. Un trucco davvero carino, perché in tal modo si può serializare qualunque cosa ;-)
Il capitolo termina con la trasformazione della parte di editing dei MultiDoc in uno user control di ASP.NET.
L’autore fa notare come l’integrazione non sia appunto ancora totale, speriamo in futuro.
Il capitolo 10 fa notare come IronPython possa essere usato nelle attività di amministrazione di Windows giornalmente.
I post precedenti sono: WPF, protocolli e metaprogrammazione, testing, proprietà, dialog e Visual Studio, first class functions e xml, applicazioni e design pattern, oggetti .NET e IronPython, introduzione a Python, introduzione al libro e il preambolo.
L’autore si butta nell’interfacciamento a WMI e PowerShell. Personalmente non immaginavo nemmeno che si potesse integrare PowerShell dentro IronPython e viceversa. Stellare :-)
La forza di Python nell’amministrazione di sistema sta nella versatilità, nella possibilità di usare il paradigma che si preferisce e nel fatto di avere tutta la ricchissima libreria a disposizione anche per i semplici script. È usato giornalmente per interfacciarsi agli ambienti Unix, a Win32 e per qualsiasi tipo di automazione nel sistema operativo.
Python ha un sacco di moduli per l’amministrazione di sistema: os per la gestione del sistema operativo (compresa la gestione di processi), os.path per i path, sys per le informazioni del sistema e gli standard input, output ed error, stat per gestire gli attributi dei file, shutil per operazioni di copy, move e delete ad alto livello e altri ancora.
Per mostrare tutto ciò l’autore crea un sottoinsieme dell’utility find di Unix (utilissa se volete trovare dei file in un albero di directory). Questo gli permette di dimostrare il parsing della linea di comando, la lettura di file INI, la navigazione delle directory ricorsivamente (usando generatori) e il pattern matching sui nomi dei file.
Un’altra tecnologia utilissima è WMI per ricavare informazioni dal sistema operativo sui processi, sulle macchine, sulla rete ecc. ecc. Usando System.Management e WQL si possono fare cose davvero interessanti ;-)
Il capitolo si conclude con una serie di esempi davvero esoterici dove si mostrano le interazioni tra PowerShell e IronPython in entrambi i sensi. Addirittura si possono usare i blocchi di PowerShell come event handler da IronPython!!
Ah, IronPython, ovviamente, può interagire anche con COM.
La terza parte del libro si butta intensamente sull’uso di IronPython negli scenari più disparati di .NET. Da WPF a PowerShell a ASP.NET a praticamente qualsiasi cosa sia usabile in .NET.
Il capitolo 9 tratta Windows Presentation Foundation.
I post precedenti sono: protocolli e metaprogrammazione, testing, proprietà, dialog e Visual Studio, first class functions e xml, applicazioni e design pattern, oggetti .NET e IronPython, introduzione a Python, introduzione al libro e il preambolo.
Il capitolo parte con una introduzione a WPF e continua presentando un esempio di UI sviluppata in WPF via codice e un altro esempio sviluppato usando XAML (caricato via codice tramite la classe System.Windows.Markup.XamlReader).
Fa riferimento ai vari tool per progettare UI visualmente: IronPython Studio, Visual Studio ed Expression Blend. Insomma, ce ne sono parecchi di modi :-)
Il secondo esempio in cui si butta l’autore è una UI più ricca che fa uso di varie controlli tra cui: Grid, ComboBox, CheckBox, Image, Expander, ScrollViewer, TextBlock.
Altri esempi includono l’uso della classe XamlWriter per serializzare le UI in XAML e la visualizzazione di documenti XPS dentro una applicazione WPF.
Come potete immaginare c’è un sacco di materiale in questo libro.