Beitrag von Andreas Jurenda (32 Beiträge) am Montag, 19.März.2001, 08:48.
@Sander: Doku zu Formularen
Hallo Sander:
Danke für die Aufnahme der Formulare in die Doku, ABER:
Dir ist da bei http://baseportal.de/cgi-bin/baseportal.pl?htx=/hilfe/baseportal/db_help&help=98 jedoch etwas passiert, was die Sache für "Neulinge" schwerer macht:
Bei allen input-Feldern fehlt nach name das "=".
Interessant ist auch die Geschichte mit dem ":=", denn bei von BP automatisch generierten Formularen steht bei den hidden-Feldern nur ein "=", und bei allen name-Einträgen gibt es nie "-Anführungsstriche?!?
Hier ein Auszug aus einem Standardforular (etwas formatiert):
<FORM
action=baseportal.pl? Id=0&htx=/templatename&
cmd=mod&range=0,20 method=post
encType=multipart/form-data>
<INPUT type=hidden value=0 name=Id=>
<INPUT type=hidden value=/templatename name=htx=>
<INPUT type=hidden value=mod name=cmd=>
<INPUT type=hidden value=0,20 name=range=>
...
Mitglied:<INPUT value=Andreas name=Mitglied:=>
...
Was ich ebenfalls nicht verstehe ist, warum der Inhalt der hidden-Felder auch im Aufruf der Basismethode von BP stehen muß?!?
Herzliche Grüße von Andreas Jurenda :-})
Antworten
Beitrag von Sander (8133 Beiträge) am Montag, 19.März.2001, 15:12.
Re: @Sander: Doku zu Formularen - oje, wird...
...sofort geändert ;-)
>>und bei allen name-Einträgen gibt es nie "-Anführungsstriche<<
>>denn bei von BP automatisch generierten Formularen steht bei den hidden-Feldern nur ein "="<<
>>Was ich ebenfalls nicht verstehe ist, warum der Inhalt der hidden-Felder auch im Aufruf der Basismethode von BP stehen muß?!?<<
meinst du damit, warum cmd= und htx= nochmal als hidden mitgeschickt wird? - Es kann bei einigen Browsern Probleme geben, wenn get und post gemischt wird, dh. es wird einfach in der url ignoriert (wenn ich damals Christoph richtig verstanden habe ;-))
Sander
Antworten
Beitrag von Andreas Jurenda (32 Beiträge) am Dienstag, 20.März.2001, 00:24.
Re: @Sander: Doku zu Formularen - oje, wird...
Danke, habe ich auch schon begutachtet.
Verdammt, ich bin als Informatiker zu fixiert auf black-box-Denken und dazu ist eine exakte Definition der black-box Ein- und Ausgaben Voraussetzung. OK, ich habe gelernt, die black-box selber zu erforschen, damit ich Ungereimtheiten der Doku aus dem Weg räumen kann.
Bei Eurer BP (B_lack---P_ox ;-)) habe ich da noch eine Menge an Probleme:
Die Geschichte mit den hidden cmd= und htx= (und den weiteren range= und Id== (oder Id=...)) ist nicht ganz klar: Was passiert, wenn cmd= bzw. htx= der hidden-Felder nicht mit denen der URL übereinstimmen? Welche (im URL oder hidden) kann man unnötigerweise weglassen?
Ich habe mich in den letzten Tagen mit dem <do action=input> auseinandergesetzt, und habe hier nur Ungereimtheiten gefunden. Dabei bin ich mittlerweile so durcheinander geraten, daß ich meine seltsamen Ergebnisse (auch in Hinblick auf den Inhalt von %_get, %_put und %_sel) nicht mehr wiedergeben kann. Eines der interessantesten Ergebnisse war, daß bei Übergabe eines Formulars an ein <do action=input> alle Datensätze gleichermaßen verändert wurden. Ach ja, und in der Regel waren die Id's durcheinander.
<do action=all> dürfte ausgereift und einsetzbar sein. Bei <do action=input> habe ich es zwar geschaft, meine Daten zu verändern, aber im gleichen Template, wo das <do action=input> steht, ist eine Ausgabe des gesamten Datenbestandes unmöglich, denn die Eingrenzung mit Id== ist nicht wegzubekommen.
Herzlich Grüße von Andreas Jurenda :-})
Antworten
Beitrag von Sander (8133 Beiträge) am Dienstag, 20.März.2001, 01:43.
Re: @Sander: Doku zu Formularen - oje, wird...
hmmm, ich versteh deine Probleme nicht.
Außer das mit cmd u.ä. im hidden. Willst du alle Browser bedienen, muß es doppelt geschrieben sein. Der eine übernimmt es aus der URL, der andere aus dem hidden feld - willst du einige User nicht ausgrenzen, schreibe beides.
Für den Rest muß dir mal Christoph antworten, er schläft ja praktisch in BP ;-)
Sander
Antworten
Beitrag von Andresa Jurenda (1 Beitrag) am Dienstag, 20.März.2001, 08:43.
Re: @Sander: Doku zu Formularen - oje, wird...
TS=01:43 Na, Du hältst ja auch nicht wirklich viel vom Schlafen ;-)
Die Rolle des Browsers ist mir da nicht ganz klar, denn das Zeug aus der URL und den hidden-Feldern hat das Template von BP zu verarbeiten!
Das Zeug aus der URL ist meiner Meinung nach unnötig, denn die hidden-Felder müssen alle Browser mitschicken, denn sonst wären die meisten Anwendungen von Formularen nicht umzusetzen und funktionsfähig.
Ich hege hier jedoch einen viel gravierendern Verdacht:
BP hat nie die Schnittstellen (baseportal.pl und die do action-Tags) eindeutig definiert, wodurch die einzelnen Elemente von BP mal auf die URL mal auf die hidden-Felder zugreift.
Daraus folgt, der Inhalt in den hidden-Feldern und der URL muß immer übereinstimmen, sonst kann niemand voraussagen, was denn nun beim Aufruf passieren wird.
Da kommen wir auch wieder auf den Ursprung meiner DOKU-Kritik: Ich möchte die Definition der BP-Schnittstellen, damit ich vorher weiß, was nacher passiert (oder passieren soll). Derzeit bewege ich mich im Bereich der Grundlagenforschung mit Ausprobieren von: Was macht BP wenn...
Herzliche Grüße von Andreas Jurenda :-})
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Mittwoch, 21.März.2001, 16:57.
Re: doch doch...
Die baseportal-Schnittstellen sind klar definiert, wenn dann gibts Ungereimtheiten in der Doku ;-)
Nochmal zu dem Punkt, warum die Sachen in der URL UND im Formular mitgeschickt werden und zwar jetzt so klar und konkret wie nur irgend möglich: ;-)
Also, ein Nutzer gibt etwas in ein Formular ein und schickt es ab. baseportal erhält die Daten und speichert sie in der DB und schickt eine Antwortseite. So, nun gibt es Fälle wo der Nutzer diese Seite reloadet haben will (warum auch immer, es gibt manchmal Gründe) - drückt er "Reload" beim Browser ist das sicher der falsche Weg, weil dann die Daten nochmal in der DB gespeichert werden. Stehen die nötigen Aufrufdaten aber in der URL kann er zumindest in die URL klicken und Return drücken. Wenn er sich auskennt, kann er da sogar die Parameter ändern, wozu man zugegebenermassen schon etwas tiefer in der Materie stecken muss, aber warum sollte man es nicht ermöglichen? Und: Würde man die "Statuswerte" (range, htx etc.) _nicht_ in der URL übertragen, stünde dort nur ein "http://baseportal.de/cgi-bin/baseportal.pl" und das gefällt mir nicht - ich finde es besser wenn zu jeder Seite die man im Browser sieht auch die entsprechenden "Aufrufwerte" dabei stehen...
Einer der beiden Browser kann damit umgehen, wenn man URL + Formularangaben ("get" + "post") mischt, dann hätte man die "Aufrufwerte" in der URL und die "Daten" (Also was in die Datenbank geschrieben werden soll) im Formular machen können, aber der andere Browser kommt damit nicht klar, also stehen die "Aufrufwerte" doppelt da, in der URL und im Formular.......
So. Das ist alles. Sonst steckt da nichts dahinter. Man kann nun sicher darüber diskutieren, ob das alles sinnvoll etc. etc. ist, aber ich kann keinerlei Nachteil sehen (ausser ein paar Bytes die mehr übertragen werden, naja).
Uffz, zufriedenstellend geantwortet? ;-)
Antworten
Beitrag von Andreas Jurenda (32 Beiträge) am Dienstag, 20.März.2001, 09:35.
Re: @Sander: Doku zu Formularen - oje, wird...
>Sander wrote:
>hmmm, ich versteh deine Probleme nicht.
Ich habe es folgendermaßen verstanden:
<do action=all> macht die Verarbeiteung der Eingabe (Daten, die von einem Formular geschickt werden) und natürlich die wunderschöne Ausgabe, je nach dem aktuellen Zustand: Liste, Ändern&Löschen, Hinzufügen, Detail und Formular.
<do action=input> Stellt eine "Untermenge" von >all< dar und bewerkstelligt die Verarbeitung der von einem Formular geschickten Daten.
<do action=list> Macht den Rest, von >all<, den >input< nicht macht.
Ich bin davon überzeugt, daß ihr das auch so geplant habt, nur: ES GEHT LEIDER NICHT!
<do action=all> ist ausgereift und funktioniert.
<do action=input> funktioniert einigermaßen, aber es gibt Probleme!
<do action=list> ufff, damit habe ich mich noch nicht gespielt, da dessen Funktionalität jene ist, die ich für meine Anwendung selber machen muß.
Nun die Problembeschreibung:
Ich möchte mich nicht mit der Verarbeitung der vom Formular gesandten Daten (POST) herumschlagen. Ich hab' mir mal den Inhalt von %_put angeschaut, nein danke!
Die von Euch vorgegeben Listenausgabe (in >all< und >list<) ist für mein Problem nicht brauchbar, weshalb ich diese Sache selber mit >loop< programmiert habe und funktioniert perfekt (war nicht schwer).
Somit habe ich es genauso gemacht, wie Ihr in Euren Default-Templates.
Nur das ich statt <do action=all> ein <do action=input> und eine eigene Ausgabe gemacht habe.
Das Formular zum ändern steht in einem 2. Template.
Funktioniert bestens, bis ich vom Formular wieder mein Ausgangstemplate aufrufe:
<do action=input> funktioniert perfekt, jedoch die Ausgabe geht nicht mehr! Ursache dafür ist die Eingrenzung durch den Aufruf mit Id==n im URL und im hidden-Feld. Dieses Id==n grenzt mir den Zugriff auf die Tabelle auf den geänderten Datensatz ein. Diese Eingrenzung ist, solange dieses Template offen ist, nicht wegzubringen!
Das das aber funktionieren muß, beweist die Tatsache, daß es in <do action=all> ja vortrefflich funktionert!!!
Also verratet, was ihr in Eurem <do action=all> für Dinge dreht, wodurch es bei Euch funktioniert und bei meiner veränderten Situation mit <do action=input> und eigener Ausgabe nicht.
Herzliche Grüße von Andreas Jurenda :-})
PS: Meine Eingangs dargestellte Zusammenfassung steht so nicht in der DOKU. Könnte man dort beim ersten Auftreten der Parameter von <do action=...> einfügen ;-)
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Dienstag, 20.März.2001, 18:54.
Re: do input/list/all
Anscheinend machst Du den Fehler, die Id mit "==" zu übertragen (was eine Datenbank-Auswahl ist). <do action=input> erwartet das aber als "normalen" Wert, also mit "Id=xx", sowie den Parameter "cmd=add" (oder "mod" oder "del")
Die Beschreibung von <do action=list> stimmt nicht gant, es macht nur die Listenausgabe, nicht "den Rest", es fehlen z.B. die ganze Reiter...
Was hast Du gegen %_put? Ist doch einfach:
enthält z.B. den Wert des Feldes "Name"... ;-)
Antworten
Beitrag von Andreas Jurenda (32 Beiträge) am Dienstag, 20.März.2001, 22:36.
Re: do input/list/all
Volltreffer!
Hmm, ist mir etwas peinlich, denn das hätte ich selber sehen müssen! Aber vielleicht hab' ich in letzter Zeit so viel herumprobiert, daß ich blind geworden bin.
Jetzt machts genau das, was ich mir vorgestellt habe.
Frage: wird bei "cmd=add" und "Id=xx" der neue Datensatz bei der Stelle "xx" eingefügt und der Rest zu "xx+1" hin verschoben?
Ich hab nichts gegen %_put, solange Textfelder stehen, aber bei meinen Checkboxes kommen dann immer so seltsame ARRAY(0xnnnnnn)-Dinge. OK, ich weiß, mit [] (oder sähnlich) wirds lesbar, aber ich mag nicht unbedingt sehr viel Nachdenken müssen, wenns zu vermeiden ist.
Und mit <do action=input> brauch ich mich nicht darum kümmern.
Herzliche Grüße von Andreas Jurenda :-})
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Dienstag, 20.März.2001, 23:17.
Re: do input/list/all
Nein, das war etwas unklar von mir hingeschrieben - "Id=xx" macht bei "cmd=add" keinen Sinn, es wird dabei immer ein Eintrag _hinzugefügt_. Da dies eine Datenbank ist, gibt es keine feste Ordnung - Du kannst Dir die Inhalte in jeder beliebigen Ordnung ausgeben lassen, solange Du ein entsprechendes Feld definiert hast - die Ids sind interne "Bezeichner" (nötig z.B. für "mod" oder "del"), das hat nicht direkt was mit einer Ordnung zu tun, das ist nur ein "nicht vermiedener" Nebeneffekt...
Bei checkboxen? Mhh, muss ich mir mal anschauen, aber da sind dann die berühmten verschachtelten Datenstrukturen am Werk: $_put{Feldname}[0] wäre dann nötig...
Antworten
Beitrag von Andreas Jurenda (32 Beiträge) am Dienstag, 20.März.2001, 22:54.
Re: do input/list/all
rtfm!
Ihr habt euer eigenes Manual noch nicht gelesen!
Es stimmt, was Du schreibst mit
>Die Beschreibung von <do action=list> stimmt nicht ganz, es macht nur die Listenausgabe, nicht "den Rest", es fehlen z.B. die ganze Reiter...
Ich habs gerade ausprobiert! AAAAABER in Eurer Doku steht sogar ein Beispiel drinnen wo behauptet wird, das das geht. Bis jetzt hab' ich ja nur kritisiert, was alles in der Doku fehlt, aber da sind ja auch Sachen drinnen, die gar nicht so funktionieren, wie ihr es beschreibt!
Zum selber Nachlesen hier der entsprechende Link: http://baseportal.de/cgi-bin/baseportal.pl?htx=/hilfe/baseportal/db_help&help=46
Weiters schreibt ihr, daß ALLE unter Parameter http://baseportal.de/cgi-bin/baseportal.pl?htx=/hilfe/baseportal/db_help&help=62 aufgeführten Parameter je nach Listtyp einsetzbar wären.
Herzliche Grüße von Andreas Jurenda :-})
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Dienstag, 20.März.2001, 23:25.
Re: do input/list/all
Stimmt, wir schreiben nur was hin, ohne zu verstehen, was es bedeutet ;-)
Nein, im Ernst: Tja, das ist dann wohl ein Fehler, "listtype=all" gibt Die detailausgabe eines eintrags aus... Und das zweite: Naja, ist etwas undeutlich formuliert, es steht ja da "Alle Parameter sind je nach listtype möglich" - müsste wohl besser "Verschiedene Parameter..." heissen...
Antworten
Beitrag von Andreas Jurenda (32 Beiträge) am Mittwoch, 21.März.2001, 10:53.
Re: do input/list/all ... Vorschlag
Tschuldigung, daß Du meine DOKU-Kritik in die falsche Kehle gekriegt hast, ABER:
Macht Euch doch das geniale Werk BP nicht selber kaputt. Ich bin ja nicht der Einzige, der über die Doku unkt.
OK, Sander (Danke übrigens) hat die Doku nachgebessert aber dann doch nur ein viertel (= einhalb mal einhalb), denn einerseits ist der Abschnitt Formulare unvollständig (nur add ist behandelt) andererseits betrifft die Nachbesserung leider nur die online-Doku. Die Offline-Doku ist veraltet. (Forum=>) Für die Anwender sind die Mascherln in der superdelux-Ausgabe bei der PDF-Doku weniger wichtig, als das die PDF-Doku inhaltlich vollständig ist!
Zum Themenkreis do.... habe ich mich etwas gespielt und jeder kann sichs hier anschauen:
http://baseportal.de/cgi-bin/baseportal.pl?htx=/jurenda/test/Test_Do_Action_All
Schade, daß bei <do action=input> keine Register erzeugt werden.
Hierzu könnte ich mir 2 Verbesserungen vorstellen:
1) ergänzt Euer System mit <do action=control> womit die Registersteuerung umgesetzt wird, wodurch die Aufteilung von all in input, register und list komplett wäre. In diesem Tag würden auch alle Parameter, die zum Blättern gehören, berücksichtigt.
2) Bei der Bezeichnung einiger Parameter und Parameterwerte ist Euch leider eine Inkonsistät unterlaufen:
a) do_all (siehe weiter unten mehr)
b) listtype=all (anstelle von detail)
c) allfields=...
d) detail= (hier heißts jedoch detail!!!)
all wird zweimal für Alles_machen eingesetzt (bei <do action=all> und bei do_all (entgegen der Doku!!! mehr siehe weiter unten), einmal in der Doku bei do_all für Alles_ausgeben, und bei listtype=all bzw. allfields=... für Detail_ausgeben bzw. Detail_Felder.
Hier würde ich folgende Korrektur bei den Namen vorschlagen:
all - wird nur dann verwendet, wenn Alles_machen gemeint ist.
full - wird für Alles_ausgeben eingesetzt (hmm, der Name schmeckt mir im Moment nicht ganz => do_full???)
detail - wird für Detail_ausgeben und Detail_Felder eingesetzt.
Daraus ergeben sich folgende Konsequenzen:
allfields=<(-)feld1,feld2..>/#<anzahl> wird ersetzt durch
=> detailfields=<(-)feld1,feld2..>/#<anzahl> und der Parametername allfields ist mit detailfields identisch (kompatibilität)
listtype=list/full/detail/add/search wird um full erweitert
=> listtype=all ist identisch mit listtype=detail
=> listtype=full ist der Defaultwert und erzeugt "nur" die Ausgabe <do action=list> unter Auswertung von cmd=do_add/do_search/do_mod.... je nach Inhalt der URL
do_all in der Doku bezeichnet "nur" die Ausgabe von <do action=all>. Das ist aber nicht korrekt, denn do_all führt alles durch (auch das <do action=input>. Ich war sehr erstaunt, die nach <do action=input><perl>do_all</perl> der neue Datensatz 2 mal erstellt wurde!
Vielleicht sollte man do_all folgendermaßen fortsetzen:
a) do_all macht einfach wirklich alles
b) do_input sollte gleichstehen mit <do action=input>
c) do_list anstelle von list, denn list ist in der Doku ja eh' noch nicht beschrieben.
d) do_control um die Register zu erzeugen.
Ach ja, da ist mir noch was aufgefallen: Bei den Defaulttemplates von BP steht in den URL für die verschiedensten Sachen wie Ändern, Suchen, Neu,... immer in der URL ein cmd=list&cmd=do_mod, cmd=list&cmd=do_search, cmd=list&cmd=do_add,... (Parameter, die dazwischen stehen hab ich weggelassen).
Ist das OK? Kann man im Hash mit $_get("cmd") auf beide zugreifen?
Noch eine Frage: Wie kann ich bei den Defaulttemplates (z.B.: <do action=all>) das "Löschen" unterbinden und zwar nicht mit einem Workaround sondern mit der Angabe eines Parameters wie vielleicht delete=no.
Uff, hoffentlich habe ich mich in dem langen Text nicht irgendwo geirrt, aber das Textfeld vom Forum ist für derartig lange Sachen zu klein.
Herzliche Grüße von Andreas Jurenda :-})
Antworten
Beitrag von Sander (8133 Beiträge) am Mittwoch, 21.März.2001, 14:53.
Re: do input/list/all ... Vorschlag
du schreibst:
>>OK, Sander (Danke übrigens) hat die Doku nachgebessert aber dann doch nur ein viertel (= einhalb mal einhalb), denn einerseits ist der Abschnitt Formulare unvollständig (nur add ist behandelt) andererseits betrifft die Nachbesserung leider nur die online-Doku. Die Offline-Doku ist veraltet. (Forum=>) Für die Anwender sind die Mascherln in der superdelux-Ausgabe bei der PDF-Doku weniger wichtig, als das die PDF-Doku inhaltlich vollständig ist!<<
Da ich auch nur ein normaler Anwender bei BP bin, der nur ein bisschen die Doku pflegt, sind mir auch nicht alle Befehle klar und die Struktur die dahinter steht. Es gab mal eine Zeit, da haben alle nach einer besseren Doku geschriehen - da kam die Initiative auf "User schreiben selbst" - und keiner wollte mitmachen!!! Also, der Fehler mit list=all geht eindeutig auf mich - ich habe es nie gebraucht und nur falsch kombiniert :-( . Aber ein Formularbeispiel mit del und mod ist so komplex - ich denke das würde den Rahmen sprengen. Es ist in dem Fall sogar sauberer nur mit Perl zu arbeiten, da weißt du genau was passiert.
Offlinedoku: Es ist ja nicht so, das ich kompletten Zugriff auf BP-Verzeichnisse habe, ich bereite das vor und schicke es Christoph, damit er es auf den Server stellt. Das dauert natürlich seine Zeit.
dein problem mit <do action=input> und do_all in Perl ist ganz leicht nachzuvollziehen. input schreibt den Datensatz und do_all genauso, weil ja das input in do_all mit drinsteckt. In der doku steht ja auch komplett alles von <do action=all>, da zählt input dazu.
Also, wenn du denkst das System verstanden zu haben und gern was zur Doku beisteuern möchtest, sag Bescheid.
Sander
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Mittwoch, 21.März.2001, 17:13.
Re: do input/list/all ... Vorschlag
Ich will mich garnich lange ausmergeln, muss nur nochmal betonen, dass Sander momentan auf völlig freiwilliger Basis arbeitet und dafür sehr viel leistet und er seine Arbeit sehr gut macht und ich sehr froh bin über diese Entlastung (Programmierer dokumentieren ja bekanntlich nicht gern ;-) )... Insofern kannst Du (Andreas) ihm garnichts vorwerfen, sondern halt baseportal (und damit mir), dass es nicht perfekt ist, aber wer oder was ist das schon...? ;-)
Kritik ist natürlich immer willkommen, noch besser konstruktive Kritik und das machst Du ja auch, prima wärs, wenn Du die geforderten Texte gleich selbst schreiben würdest ;-)
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Mittwoch, 21.März.2001, 16:45.
Re: warum Werte doppelt als "post" und als "get" übertragen werden...
Antworten
Beitrag von Ruben (403 Beiträge) am Mittwoch, 21.März.2001, 10:54.
@Andreas Jurenda - Re: @Sander: Doku zu Formularen
Mhm, kann mirs nicht verkneifen, hier mal meinen Senf dazuzugeben!
Es ist eine Sache in und mit Baseportal arbeiten und eine andere, es unbedingt auseinander und "buggy" reden zu wollen!
Sicher, es sind einige Dinge nicht sofort klar zu verstehen - aber das ist noch lange kein Grund, Probs zu "produzieren".
Ich gehe ausschließlich von der Zielvorstellung aus und baue solange, bis diese (weitestgehend) erreicht ist. So sollte auch ein Informatiker wie du an die Sache herangehen. Und dann sind hier im Forum die Fragen, wie man weiterkommt immer gut beantwortet.
So kann man den Umgang mit bp lernen, auch die Eigenheiten herausfinden und damit umgehen.
Wenn du in Windows arbeitest, muß du auch dessen Eigenheiten beachten - wenn nicht, kommst du auch ins Schleudern. Und auf die Idee, zu hinterfragen, wie die BlackBox Windoofs in allen Einzelheiten funzt kommt auch keiner oder? APIs werden genutzt, deren Definition und Funktion (und auch Bugs) als gegeben hingenommen und man hält sich an diese, wenn man was erreichen will.
So ist es halt hier auch. Nur ist das "Schicht-Level" ein anderes.
Die "High-Level"-Befehle do mit allen Parametern sind schnell ausgetestet und man kann sie einfach einsetzen. Da ist halt listtype=list ne Listenausgabe (und mehr nicht) und do action all läßt alles zu, abhängig von den gesetzten "Primärrechten" in der Datenbank. Wenn da halt sowohl in der URL als auch als in hidden-fields Werte übergeben werden müssen, dann wird das halt gemacht (hab aber die Erfahrung gemacht, daß das gar nicht notwendig ist, jedenfalls mit IE 5 und NS 4.7 nicht) - wer fragt denn schon, wenn bspw. in Win für jedes Programm bei der Dateiendungsdefinition für OLE/DDE die Parameter absolut unterschiedlich gehandelt werden?
Es sind "Schnittstellen" bei bp definiert, und das ganze m.E. recht eindeutig und klar - die Doku ist unterdessen soweit ausgebaut, daß sie als Referenz ordentlich nutzbar ist.
Und für Ziele, die mit dem "einfachen" do nicht erreichbar sind, finde ich die Programierbarkeit mit Perl eine absolut gelungene Möglichkeit.
Sicher ist der Ansatz von bp anfangs nicht einfach zu verstehen, da allgemeine Vorstellung bei Datenbanken in Richtung SQL o.ä. geht. Aber die Einfachheit der Datenhaltung als Textinhalte (ich denk mal mit meinen wenigen Perl-Kenntnissen, daß die Daten in nem Textfile in einer Art großen "hash" bei bp verwaltet werden) ist m.E. viel einfacher zu nutzen als bspw. ne Access-Datenbank. Und schließlich ist da noch die absolute Unabhängigkeit von irgendwelchen Servererweiterungen beim Provider - alles über bp und das ganze (unterdessen) absolut zuverlässig und blitzschnell!
Also, bitte nicht zerreden, sondern nutzen, probieren, verbessern und Erfahrungen teilen.
CU
Ruben
Antworten
