Re: Neue CPANmodule

Hi Moritz,
Moritz Bunkus schrieb:
> On Monday 02 April 2007 15:54, Udo Spallek wrote:
>> sehr gern würde ich die folgenden CPAN Module für Lx-Office benutzen:
>> - Class::DBI
>> - Class::Std
>> - Contextual::Return
>> - CGI::Carp
>> - Regexp::Common
> Ich hab eben mal bei Ubuntu 6.06 und bei OpenSuSE 10.2 nachgesehen,
> welche Pakete davon Bestandteil der Distribution sind und welche nicht:
> 
> Modul              Ubuntu OpenSuSE
> Class::DBI         ja     nein
> Class::Std         nein   nein
> Contextual::Return nein   nein
> CGI::Carp          ja     ja
> Regexp::Common     ja     ja
> Sieht etwas gemischt aus.
hmm... ich würde immer den Weg über perl -MCPAN... einschlagen, ist 
sowieso viel einfacher, aktueller und konsistenter.

>> Class::DBI ermöglicht einen objektorientierten Zugriff auf die
>> Datenbank und ist dabei datenbankunabhängig.
> Ehrlich gesagt finde ich das absolut überflüssig. Wir stellen hier
> gerade alle .pms auf parametrisierte Queries um und führen dabei immer
> mehr Hilfsfunktionen in DBUtils.pm ein. Das mag zwar nicht die absolut
> objektorientierte Version sein, aber wozu brauchst du dieses Modul, wenn
> DBI selber bereits objektorientiert ist?
Ähm, die DBI bietet aber keinen oo Zugriff auf eine Datenbank und 
genau das ist der Unterschied. Ich kann mit class::dbi den 
Datenbanklayer in meinem Modul abbilden und dann nur noch auf die 
Abbildung zugreifen. Wenn sich etwas änndert, dann muss nicht gleich 
an jeder Stelle angepasst werden, sondern nur noch an einer.

Class::DBI ist mir _noch_ nicht so wichtig, da ich bisher sowieso 
nur 30 Codezeilen da hinein investiert habe.
Hab gerade deine weitere Mail gelesen... lass es raus, ich schreib um.

> DBI ist ebenfalls
> datenbankunabhängig. Und es gibt immer genügend Stellen bei
> SQL-Anfragen, die von einem Modul überhaupt nicht datenbankunabhängig
> realisiert werden können, da muss der Programmierer halt ran (denk nur
> an Subqueries... Die werden z.B. von MySQL gar nicht oder nur bei
> bestimmten Tabellentypen unterstützt).
Datenbankunabhängigkeit sehe ich auch eher im Kontext von Standard 
SQL. Das kann halt jeder... Mysql brauche ich nicht...

>> Mit Class::Std ist es möglich, sog. inside-out Klassen zu
>> generieren, die sich dadurch auszeichnen, vollständig gekapselt zu
>> sein. Im Gegensatz zu hashbasierten Klassen müssen alle
>> Objektattribute in der Klasse deklariert werden, und können nicht
>> clientseitig 'reingebastelt' werden, was zu einer konsistenten
>> Schnittstelle führt.
> Klingt durchaus sinnvoll.
Dieses Modul brauche ich schon sehr dringend, da ich die 
Klassenstruktur für die taxkeys-chart-tax Anbindung damit bereits 
realisiert habe.

>> Contextual::Return bietet die Möglichkeit, kontextbasierte
>> Rückgabewerte für Funktionen oder Methoden zu generieren. Dabei ist
>> es weitaus mächtiger und einfacher zu verstehen, als wantarray...
> Ebenfalls sinnvoll.
Brauch ich auch, hab ich auch schon drin. Ist aber bisher nur für 
den Konstruktor nötig gewesen...

>> CGI::Carp ermöglicht es Fehler auszulösen und Meldungen zu erzeugen,
>> die aus Aufrufersicht (Frontendcode) formuliert sind. Diese sind zum
>> debuggen deutlich sinnvoller als die, welche von 'die' erzeugt werden.
> CGI::Carp sollte doch eigentlich immer drauf sein, wenn CGI selber
> installiert ist, glaube ich.
Das ist eine Sache, die müssten wir auf jeden Fall nochmal gemeinsam 
testen. Alle 'die's im Backendcode erzeugen relativ sinnlose 
Zeilenangaben, wenn eine Exeption ausgelöst wird. Denn meistens ist 
es wenig erhellend zu wissen, dass der Fehler letztendlich in Modul 
xy Zeile z ausgelöst wurde. Viel interessanter ist es zu wissen, von 
welcher anderen Funktion die betroffene Routine aufgerufen wurde und 
ob deren Übergabeparameter stimmen...

>> Ferner sollten wir überlegen, verschiedene RegExe's über das Modul
>> Regexp::Common zu realisieren. Dieses Modul ist sehr mächtig und in
>> der Lage zuverlässig (175000 Tests! Umfassendste Testsuit des CPAN)
>> tatsächlich das heraus zu filtern was man wirklich will...
> Hmm, naja. Wenn du meinst, dass man's braucht... Ich bin etwas
> skeptisch, wenn immer mehr und mehr (vor allem große) Module bei jedem
> Zugriff geladen werden sollen.
Ja und Nein. Fast alle Regexe die wir in Lx benutzen sind sehr 
fragil. Außerdem wiederholen sie sich ständig, was die Pflege quasi 
unmöglich macht. Ich sage nicht, den Altbestand komplett 
durchzugehen und alle Regexe auszutauschen. Sondern nur, das wir die 
Möglichkeit bereitstellen sollten, auf gute Regexe zurückgreifen zu 
können.
Wir haben bisher noch nicht in die Richtung getestet, was eigentlich 
passiert, wenn man diese und jene Zeichenkette in Feld xy an Lx 
übergibt...
Warum lassen wir in diesem empfindlichen Bereich nicht die Perl 
Meister ran, die sich wirklich gut mit der Regex Engine auskennen?!
Lies mal Kapitel 12 in Perl Best Praktices um einen Eindruck von der 
Qualität unserer Regexe zu bekommen...
Das Modul wird einfach als Hash eingebunden und über dessen Keys 
angesprochen. Warum brauce ich das? Damit ich besseren Code 
schreiben und mich auf anderes konzentrieren kann...

>> Angekündigt werden die neuen Voraussetzungen soweit ich weiss in
>> - doc/INSTALL
>> - doc/UPGRADE
>> - SL/InstallationCheck.pm
>>
>> oder fehlt da noch etwas?!
>> Wenn niemand etwas dagegen hat, so bitte ich Linet darum, die o.g.
>> Module auf der Demoplattform nachzuinstallieren, damit ich meinen
>> Code gefahrlos einchecken kann.
> > Ja, so ganz bin ich schlicht nicht überzeugt. Bei Modulen, die nicht auf
> zumindest Debian/Ubuntu und OpenSuSE verfügbar sind, würde ich sie sogar
> lieber gleich mitliefern (wie auch CGI::AJAX). Dazu müssten die
> entsprechenden Dateien im Unterverzeichnis "modules" importiert
> werden. Das geht natürlich nur, wenn die Module rein Perl sind und nicht
> auch aus compiliertem Code bestehen.
Finde ich weniger gut diese Lösung, weil zu komplex zu maintainen.
Ich würde eher alle Anleitungen für distri-abhängige Perlmodule 
entfernen, und eine einfache Anleitung wie man ein Perlmodul 
installiert hinzufügen: (Bsw.) 
http://wiki.perl-community.de/bin/view/Wissensbasis/ModuleWieInstalliereIchEinModul#Mit_dem_Paketmanager_des_Betrieb
Oder einfach ein Skript, welches alle fehlenden Module nachinstalliert.

> Kannst du bitte mal herausfinden, welche Module die ersten drei
> (Class::DBI, Class::Std und Contextual::Return) noch benötigen?
Class::Std:  version, Scalar::Util, Data::Dumper
Class::DBI: Ima::DBI, DBIx::ContextualFetch, Class::Accessor,
             Class::Data::Inheritable.
Contextual::Return: version, Want


> Lx-Office ist schon kompliziert genug zu installieren, und es wird durch
> zu viele Module nur noch komplizierter. Gerade wenn's um
> Debian-/RPM-Pakete geht und die Module für die Distribution nicht als
> Paket verfügbar sind...
Jep, aber Lx ist auch fehleranfällig genug, um einfach mehr Sachen 
an andere getestete Moule zu delegieren...

Also nochmal auf Bindestrichlänge:
Class::DBI ist nicht so wichtig.

Schöne Grüße Udo

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV