[Allegro] Problem mit Fehlermeldung

[Bernhard Eversberg]

Am 26.08.2011 11:47, schrieb Fischer, Thomas:

> Das störende 'ad-htm' (das von  d-rtf nicht angefordert wird) wird
> wiederum von t-mail.php erzeugt:
>
> if(!isset($upT) || $upT=="") $upT="ad-htm";   // default:
> Hilfstabelle ad-htm.apt
>
> wobei $upT ein potentiell übergebener Wert ist. $upT = getval('upT');
> // Hilfstabelle
>
> Soweit ich sehe, wird t-mail.php auf praktisch identische Weise in
> all.php, avrset.php, grec.php und rset.php aufgerufen, aber nirgends
> wird upT belegt. Typischerweise sieht das so aus:
>
> echo '<select name="upA" size="">'; echo '<option
> value="e-ris">Citavi-Format (RIS)</option>'; echo '<option
> value="d-mail">Mit Sonderzeichen</option>'; echo '<option
> value="d-kasci7">Ohne Sonderzeichen</option>'; echo '</select>';
>
Ja, stimmt, das hat seine Gründe in, wie Sie schon vermuten, in
t-mail.htm.
Dieses ist Teil eines früher mal intendierten Pakets von
standardisierten Musterdateien:

   http://www.biblio.tu-bs.de/db/demo/ref_av.htm
und speziell dann
   http://www.biblio.tu-bs.de/db/demo/av_mail.htm

Nachdem dies keinen vom Sitz riß, haben wir's nicht weiter verfolgt.
Um die genannte Kalamität auszubügeln, reicht es, in av_find.php
die Zeile
"if no jump perr",
   an der Stelle
"var '$partab'",
"if not '' exp t $partab",
"if no jump perr",

rauszunehmen. Wir tun das einfach mal.

>
> Können Sie vielleicht die Fehlermeldung bereinigen oder das Nachladen
> von  'ad-htm' entfernen? Oder wollen Sie phpac mittelfristig nicht
> mehr pflegen und ganz auf a30 setzen?
Nein, das wäre denn doch zu schmalspurig, und wir können nicht den
zahlreichen Anhängern von phpac den Boden entziehen.
PHPAC ist im SVN, es steht also nichts im Wege, es zu klonen und
anderweitig selber weiterzuentwickeln und dabei solcher- und andererlei
Unerquicklichkeiten auszumerzen. Anstatt sich stets und ständig auf
"Braunschweig" zu verlassen...

> Ihre Bemerkung
>
>> Die Kombination von JavaScript, PHP und FLEX ist hinreichend
>> komplex, wie man hier wieder sieht, daß es uns veranlaßte, einen
>> radikal anderen Approach zu suchen: a30. Nur noch FLEX, sonst nix.
>
> deutet in diese Richtung, ich habe aber den Verdacht, dass a30 nicht
> die Flexibilität liefern kann, die die PHP-Programmierung der
> Webseiten bietet.
>
Sicher. Nur eben ist phhpac hinsichtlich Erweiterung und Modifikation
viel anspruchsvoller, während a30 im Prinzip weitgehend ohne PHP und 
JavaScript sowie HTML+CSS und Parametrierung auskommt. Das nun
ist anscheinend den meisten wieder gar zu einfach.
Eine hingeworfene Nebenbemerkung von mir sollten Sie nicht gleich
als verklausulierte Andeutung weitreichendster Umbrüche mißdeuten!
Sowas wie Kreml-Astrologie ist hier unangebracht; anders als dort kann
man hier jederzeit mal fragen.

B.E.