Herzlichen Dank, es bewegte sich etwas! Mit dem "if (defined($form{'action'}) ....." Ratschlag habe ich, bis auf eine Linie, alles weggebracht, bis auf

elsif ($category{$form{'category'}}) { &displist; }

wo er jetzt nachstehende Info liefert:

[Sun Jan 6 03:04:53 2013] auction.pl: Use of uninitialized value $form{"category"} in hash element at auction.pl line 207.

und ganz neu, weil ich vorher

.........cgi-bin/eab/auction.pl?setup=1

aufrief und jetzt nur noch

.........cgi-bin/eab/auction.pl

und somit keine variale übergeben wird.


[Sun Jan 6 03:04:53 2013] auction.pl: Use of uninitialized value $form{"setup"} in string eq at auction.pl line 279.
[Sun Jan 6 03:04:53 2013] auction.pl: Use of uninitialized value $form{"setup"} in string eq at auction.pl line 298.
[Sun Jan 6 03:04:53 2013] auction.pl: Use of uninitialized value $form{"setup"} in string eq at auction.pl line 298.

Offensichtlich scheint das Ding, mit dem '$form{'wasauchimmer'} generell eine Schwäche zu haben. Immerhin, die einzige Lösung dieses verbreiteten Problems, zumindest wenn man Google darüber fragt, habe ich jetzt hier gefunden.

Zu den anderen Antworten und Anregungen:

Irgendwer hat mir einmal empfohlen, doch auf ein Framework umzusteigen. Du empfiehlst mir jetzt gar PHP. Und dies auf einem Perl Forum, weshalb nicht einfach eine Java App für Iphone und Co?...

Dazu: Ich vergeude einen Teil meiner Zeit damit, mit meinen wenigen Möglichkeiten zu versuchen, etwas mit zu erhalten, was sonst, für breitere Anwenderkreise zumindest, seit Jahren kontinuierlich den Bach runter zu gehen droht, nämlich Perl.

Ich baue, oder versuche zumindest, Perl/HTML/CSS Source als moderne, transparente, brauchbare und kostenlose GPL/LGPL Anwendung für kleine und mittlere Web-Projekte zu schreiben, erstellt in einer Art und Form, dass der verwendete Source Code auch für Laien, sofern diese gutes HTML SOURCE Verständnis haben, lesbar, verständlich und somit auch editierbar bleibt.

Dazu verwende ich eine Steinzeit-Software, die auch wenn sie, gemäss Aussagen vieler, zu nichts taugt, im vergangenen Jahrzehnt nicht nur in ungezählten Anwendungen und Formen zur Anwendung kam und teilweise noch im täglichen Einsatz ist, sondern als Vorlage und Basis-Source für hochpotente Anwendungen wie z.B. Ultimate Auction dienten.

Ich besitze, buchstäblich, ein 2Giga Archiv mit allem Wichtigen aus den letzten 14 Jahren rund um die Software, sie war schliesslich eine der populärsten jener Zeit.

Ein Spezialist hat jetzt den Auftrag, das Ding so zu 'frisieren', dass, aus Kompatilitäts-Gründen mit vielleicht existierenden, aber proprietären Add-On's, die fundamentale DB-Funktion prioritär bestehen bleibt, jedoch alles darum herum über indexierte Search/Sort/Routinen abläuft.

Es dauerte 14 Tage und ungezählte Zeilen voller Ueberredungskunst und ich erhielt 14 verschiedene Script Versionen, die von einer simplen MySql Search-Routine bis zum vollen MySql-Einsatz gingen, von ihm als Muster zugestellt. Bis er begriff, dass ich mit dem Zeugs nichts anfangen konnte. Ganz einfach deshalb, weil all das mit dem bestehenden 'EA 1.5x Standard' nicht mehr kompatibel war. Als einer der 'dienstältesten' EA-Coder ist er allerdings mit dem Original Script innigst vertraut und hat noch 'Sachen' im Archiv, von denen ich (noch) träume...

Deshalb hoffe ich, dass Ihr versteht, dass ich weder den Script neu schreiben möchte, noch am bestehenden Standard etwas ändern. So haben ALLE die Möglichkeit, bestehendes zu übernehmen oder neues in Bestehendes zu integrieren. Zurzeit existieren, gemäss meiner Webliste, so gegen 100 aktive Sites mit EA-Source generiertem Inhalt. Allein hier liegt schon ein Potential, das von meiner Neuauflage irgendwie profitieren kann. Natürlich englischspraching, übrigens meine bevorzugte Script Schreibart. Man lernt so immer noch dazu... ausser PERL.

Vielleicht schafft es jemand, sich irgendwo im näheren oder weiteren Umfeld 20-40 Sponsoren mit so etwa 50 Euro pro Sponsor und Jahr gegen beste Plazierung in Form von, vom Sponsor auf Wunsch jederzeit selbst erstellbaren, Bild/Text-Ad's reinzuziehen. Mit diesem Etat, viel Esprit und natürlich einem eisernen Willen, täglicher Arbeit und langem Atem kann es klappen. Zumindest dann, wenn die Software das hält, was versprochen wird, und wenn Fehlerbehebung oder upgrades nicht in ein operationelles oder finanzelles Desaster ausmünden können.

Es gab vor 10 Jahren schon Versuche bis 300'000 Einträgen mit Standard-DB, ich selbst bis zu 25'400 Artikel zu Testzwecken laufen hatte. An zwei Orten hatte ich vergessen, die Mail abzustellen und erst, als es losging, konnte ich den Script löschen. Etwa 30'000 kamen an...

Heutige Serverpower und 'distributed' Indexing sind unsere Antworten zu Performance-Fragen und zur Vermeidung von MySql-DB Sicherheits-Problemen. Einfaches Handling, Not-Einsätze über FTP, das ist unser Konzept.

Es gibt User- Kategorie- Artikel- und Gebots/Kauf- bezogene Indexe sowie einen Index für abgeschlossene Vorgänge.

Die Benutzer Registrierdatei wird nicht mehr zur 'Anbieter-Erkennung' mit Unmengen von Artikel ID-Nummern aufgefüllt, sondern nur noch als, über Edit-Reg teilweise editierbare, Basis-ID Datei geführt.

Titel, Untertitel, Beschreibungen, etc. werden html-mässig und bis zu frei definierbaren Kurzbegriffen: 'wie' 'so' 'was' 'wenn' 'ob' 'hat' 'sind' 'usw'., gefiltert abgespeichert.

Ich erwarte von zukünftigen Benutzern, dass diese selbst Hand anlegen, um das Ding auf ihre Site optisch anzugleichen. Es sollte bei angewendeten HTML Design kein Problem sein, erstellte CSS Klassen am richtigen Ort einzubinden.

Es ist vorgesehen, die verschiedenen Bereiche in, in sich, völlig autonome 'Runtime'- Pakete aufzusplitten, so zum Beispiel der Auktions- Ansichts- Bietvorgang eines Artikels oder die Benutzer-Registrations-Verwaltung. So würde z.B. der erste Registriervorgang eines Users Jeder Abteilung ihren EIGENE Userdatei im eigenen Subordner erstellen und der Script diesen Ordner als Basis--Datei handeln.

Idiotisch?

Nehmen wir mal an, ich möchte meinen EA Commerce-Script in eine bestehende Community Anwendung integrieren, ohne dazu viel mehr als zwei drei gute Zeile Code schreiben zu müssen.

Dann müsste ich nur meinen Script anweisen, auch gleich die entsprechende(n) User-Datei(en) der Community Anwendung zu erstellen oder umgekehrt, eine Commerce Anwendungs User Datei der benötigten Anwendung zu erstellen. Welche auch immer, jede wird laufen, auch zukünftige, völlig autonom, jede für sich, aber mit fast null Aufwand, auch alle im Verbund.

Persönlich finde ich, mit Ausnahme ganzer Seiten, Header, Footer, und so, HTML Templates für Scripte wie den meinen einen technischen Schwachsinn. Dazu, kein Mensch kann damit in Wirklichkeit viel anfangen, ohne wirklich zu wissen, was er(oder sie) macht. Ultimate Auction zum Beispiel hat mehr als 220 html templates, selbst für Einzeiler oder Knöpfe!!! Und da alles noch Source Code ist und kein Wysiwyg, kann sowieso niemand, der Source nich KANN, solches bearbeiten.

Da bleib ich lieber bei 'print qq|', $variable ALIAS, PASSWORD und Co., damit Lernunfähige wie ich sich wenigstens etwas einfacher orientieren können. Was wir Greenhorns dafür nicht brauchen, sind nach hinten verschobene Code-Linien, die bei solch gestalteten Scripts irgend helfen sollen, die Orientierung nicht ganz zu verlieren.

Nichts für ungut, aber für das, was Perl Newbie Sitebauer können, wissen und brauchen, taugt die Pro-Art der Programierung wenig oder ga nicht. Mal ganz abgesehen davon, dass jeder für sich in Anspruch nimmt, es am besten zu machen. Wenn (echte) Perl Programmierer Autobauer wären, würden wahrscheinlich bald einmal alle Rad fahren, weil alle Angst davor hätten, dass das Auto von niemand anderem je gefixt werden könnte, sollte mal was schief laufen...

Auf der anderen Seite versieht man Scripts mit Headern und Texten, die mehr Lizenz-Content enthalten als der ganze Script gross ist. Interessieren tut's zwar kein Schwein, aber trotzdem macht es jede(r).

Ich bin Praktiker. Beispiel: Ich schreibe grösste HTML Parts ohne jeden \n. Weshalb? Weil, wenn richtig 'vorcodiert', HTML fehlertolerant bis zum geht nicht mehr highspeed 'durchgewaschen' wird. Am schnellsten wäre es gar, aus ganzen Scripts einen Einzeiler zu machen...! Habs gelesen und auch probiert. Stimmt. Praktiker-erfahrung, nicht Theorie. (Ich hör Euch grollen)

Mehr Zeit nehme ich mir beim Schreiben, manchmal. Wollte Euch zwar den Kopf nicht durchwaschen, aber trotzdem dem einen oder anderen etwas mitgeben. Versucht, fehlertolerant zu sein, wenn Leute wie ich, wie man bei den Funkern sagt, 'auf die QRG kommen'. Wenn ich mit Kindern spreche, versuche ich auch auf, diese technisch auf deren "Frequenzbereich" erreichen zu können. Viele von uns sind in Sachen Programmierung im frühen Kinderstadium. Und einige bleiben's wie ich. Wer aber diese als Perl-Erwachsene behandelt, schadet nicht ihnen, sondern letztlich, durch deren Abwandern auf anderes, der Sprache Perl. (Auch wenn jetzt solche reklamieren, es sei ja gar keine Sprache...)

Bitte um Entschuldigung für die teils tölpelhaften Umschreibungen, ich kann's nicht besser. Wichtig ist doch nur, dass auch von Nichtgurus einigermassen verstanden wird.

Alles Gute!
Ernie
Last edited: 2013-01-06 06:39:06 +0100 (CET)