<html><head><title>Re: [Allegro] phpac: kleines altes relikt/fehlerchen(?) in write.php gefunden...</title>
<meta charset="utf-8" http-equiv="X-UA-Compatible" content="IE=9; IE=8; IE=7; IE=EDGE" />
</head>
<body>
<span style=" font-family:'courier new'; font-size: 9pt;"> <br>
Guten Tag Herr Eversberg,<br>
danke für Ihre Nachricht.<br>
Am Mittwoch, 15. Mai 2019 um 08:34 schrieben Sie.<br>
Ihre Nachricht finden Sie am Ende dieser eMail.<br>
<br>
</span><table style =" border-collapse: collapse;" cellpadding = 1 cellSpacing = 2>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td ><span style=" font-family:'arial'; font-size: 9pt;">Am Di., 14. Mai 2019 um 10:44 Uhr schrieb Klaus Lehmann<br>
</span><table style =" border-collapse: collapse;" cellpadding = 1 cellSpacing = 2>
<tr>
<td width=2 bgcolor= #3200ff><br>
</td>
<td ><br><br>
<span style=" font-family:'courier new'; font-size: 9pt;">in der letzten write.php vom 27.7.2012 steht was merkwürdiges drin...<br>
Zeile 97 $v=str_replace("\r\n","¶",$v); // Zeilenumbruch durch Code 20 ersetzen<br>
~~<br>
was da ersetzt werden soll, ist bestimmt nicht code 20. oder?<br>
in der hexansicht ist es \xc2 und \xb6<br>
</td>
</tr>
</table>
<span style=" font-family:'courier new'; font-size: 9pt;">Da wird 13 10 (innerhalb eines Feldes) durch den Unicode C2B6 ersetzt. Daraus wird dann<br>
beim insert in den Datensatz per Tabelle der Code 20, der im allegro-DOS-Code für<br>
einen feldinternen Zeilenumbruch steht.</td>
</tr>
</table>
<span style=" font-family:'courier new'; font-size: 9pt;">na gut. ich verstehe das zwar nicht so, weil doch decimal 020 ein ganz normales zeichen ist (oder?).<br>
es soll dann so sein.<br>
<br>
<br>
aber!<br>
die Zeile 97 $v=str_replace("\r\n","¶",$v); // Zeilenumbruch durch Code 20 ersetzen<br>
sollte dann doch etwas gefälliger geschrieben werden, so?<br>
<br>
das sollte doch dann etwas gefälliger aussehen....:<br>
Zeile 97 $v=str_replace("\r\n","\xc2\xb6",$v); // Zeilenumbruch durch (umgewandelten) Code 20 ersetzen<br>
<br>
ist das OK so?<br>
<br>
<br>
<br>
<br>
</span><table style =" border-collapse: collapse;" cellpadding = 1 cellSpacing = 2>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td ><br><br>
<span style=" font-family:'courier new'; font-size: 9pt;">write.php gehört zu PHPAC. Das war insgesamt ein hochverwickeltes Gemenge von PHP,<br>
JavaScript, FLEX und Parametrierung.</td>
</tr>
</table>
<br>
<span style=" font-family:'courier new'; font-size: 9pt;">ja, ich kämpfe auch seit 2003 damit oder manchmal dagegen.<br>
phpac macht alles, was "ich" will, oder die kollegen "wollen" bzw "brauchen".<br>
auch nach 16 jahren entdecke ich immer noch kleine fehlernester, die lange übersehen wurden, oder deren funktionen nicht abgefragt wurden. 2019 wurde ich "gebeten" (ich habe mich sehr "gewehrt"), dem phpac ein anderes aussehen zu geben. die auftraggeber scheinen wohl damit zufrieden zu sein (die adresse ist NOCH nicht öffentlich! sie wird auch NICHT bekanntgegeben. bitte etwas geduld).<br>
<br>
<br>
<br>
</span><table style =" border-collapse: collapse;" cellpadding = 1 cellSpacing = 2>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td ><span style=" font-family:'courier new'; font-size: 9pt;"> Dieser Mißstand hat mit dazu beigetragen, daß man<br>
zuerst mit a30, dann a35 einen radikal neuen Ansatz gewagt hat. Darin sind PHP, JavaScript<br>
und FLEX weitestgehend separiert und separat wartbar und verständlich. Daß PHPAC noch immer<br>
hier und dort rotiert, ist ein Beispiel für das erstaunliche Beharrungsvermögen von Anwendungen,<br>
die man irgendwann mal zum Laufen gebracht hat und dann lieber nicht mehr dran rührt.</td>
</tr>
</table>
<span style=" font-family:'courier new'; font-size: 9pt;">1. "beharrungsvermögen". naja... ich sagte, ja phpac macht DAS, was es SOLL! ;-)<br>
warum soll ich dann auf a35 wechseln?<br>
<br>
2. "nicht dran rühren". hm. ich "rühre" (lirumlarumlöffelstiehl) seit 2003 dran rum. und es macht mir "zufriedene freude", zu sehen, daß man immer noch "nester" ausräuchern kann, und was besseres draus machen kann.<br>
<br>
<br>
</span><table style =" border-collapse: collapse;" cellpadding = 1 cellSpacing = 2>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td ><span style=" font-family:'courier new'; font-size: 9pt;"> Wenn aber<br>
doch, dann gibt's Unvorhersehbarkeiten, wie Ihr Exempel mal wieder zeigt. </td>
</tr>
</table>
<br>
<span style=" font-family:'courier new'; font-size: 9pt;">dem ich nur durch zufall raufgekommen bin (write.php ist nun nicht gerade die am meisten benutzte "anwendung", sie benutze ich nur für meinen "filmkritiken-index" ;-)<br>
sonst kenne ich keinen anwender für die funktion in write.php....<br>
<br>
aber wenn man dann mit einer globalen sucher auf lauter "??" stösst, stösst es einem auf. und dann man bohrt tiefer mit dem löffel ;-)<br>
reiner zufall..<br>
<br>
<br>
<br>
</span><table style =" border-collapse: collapse;" cellpadding = 1 cellSpacing = 2>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td ><br><br>
<span style=" font-family:'courier new'; font-size: 9pt;">> <span style=" font-family:'arial';">ps: wie ich darauf komme?<br>
<span style=" font-family:'courier new';">> ich habe höllischen ärger mit einem professionellem differ(auch<br>
> merger) gehabt, er hat mir wertvolle dateien zerschossen, aus der<br>
> codepage-windows-ansi hat er alles ungefragt in eine utf8-datei<br>
> umgeschrieben. UND: was höher decimal 128 in ein "?" umgewandelt!<br>
<br>
Solche Gerätschaften kann man allenfalls, wie z.B. auch PHPAC, als möchtegern-professionell<br>
bezeichnen! Besser Finger weg von sowas.</td>
</tr>
</table>
<br>
<span style=" font-family:'courier new'; font-size: 9pt;">naja.... wenn man aber nun einen differ UNBEDINGST benötigt!<br>
wie wollen "sie" eine skript-datei, die, bei mir inzwischen auf 500kb angewachsen ist, mit einer alten version "diffen"? und später "mergen".<br>
ausdrucken, rot anstreichen? die zeiten waren mal, wo ich alles ausgedruckt habe... ;-)<br>
oder via commandozeile: per linux-diff? =unbrauchbarer müll....<br>
und wenn man dann zu DREI diffende dateien hat, die eine enge querbeziehung haben? da benutzt man eben "profitools", egal ob man die finger davon lassen sollte. es gibt nischt anderes... ;-(<br>
tja.<br>
<br>
<br>
<br>
<span style=" color: #000000;">danke erstmal<br>
ihr klaus lehmann<br>
<br>
<br>
<br>
<span style=" font-family:'arial'; color: #c0c0c0;"><i>--<br>
Mit freundlichen Grüßen,<br>
Ihr Klaus Lehmann<br>
</i></span></span></span><a style=" font-family:'arial'; font-size: 9pt;" href="http://allegronet.de">http://allegronet.de</a><span style=" font-family:'arial'; font-size: 9pt; color: #c0c0c0;"><i> * eMail: </i></span><a style=" font-family:'arial'; font-size: 9pt;" href="mailto:allegronet@t-online.de">allegronet@t-online.de</a><span style=" font-family:'arial'; font-size: 9pt; color: #c0c0c0;"><i> * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843<br>
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1<br>
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;<br>
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760<br>
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig<br>
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!<br>
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind<br>
* 2011-18: Sponsor: Peter-Sodann-Bibliothek+IFLA:allegro-utf8<br>
* 2013-14: Bolero 64bit.+allegro-zdb: endlich. + eBooks<br>
* 2015-16: allegro-vufind.+ allegro-imd.Die weltgrößte(?) Filmdatenbank<br>
* 2017-18: Exporte. Marc und Co. Marc ist sehr different<br>
* 2019: All for VuFind!<br>
<br>
<br>
<br>
Am Mittwoch, 15. Mai 2019 um 08:34 schrieben Sie:<br>
</i></span><table style =" border-collapse: collapse;" cellpadding = 1 cellSpacing = 2>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td ><span style=" font-family:'arial'; font-size: 9pt;">Am Di., 14. Mai 2019 um 10:44 Uhr schrieb Klaus Lehmann<br>
</span><table style =" border-collapse: collapse;" cellpadding = 1 cellSpacing = 2>
<tr>
<td width=2 bgcolor= #3200ff><br>
</td>
<td ><br><br>
<span style=" font-family:'courier new'; font-size: 9pt;">in der letzten write.php vom 27.7.2012 steht was merkwürdiges drin...<br>
Zeile 97 $v=str_replace("\r\n","¶",$v); // Zeilenumbruch durch Code 20 ersetzen<br>
~~<br>
was da ersetzt werden soll, ist bestimmt nicht code 20. oder?<br>
in der hexansicht ist es \xc2 und \xb6<br>
</td>
</tr>
</table>
<span style=" font-family:'courier new'; font-size: 9pt;">Da wird 13 10 (innerhalb eines Feldes) durch den Unicode C2B6 ersetzt. Daraus wird dann<br>
beim insert in den Datensatz per Tabelle der Code 20, der im allegro-DOS-Code für<br>
einen feldinternen Zeilenumbruch steht.<br>
<br>
write.php gehört zu PHPAC. Das war insgesamt ein hochverwickeltes Gemenge von PHP,<br>
JavaScript, FLEX und Parametrierung. Dieser Mißstand hat mit dazu beigetragen, daß man<br>
zuerst mit a30, dann a35 einen radikal neuen Ansatz gewagt hat. Darin sind PHP, JavaScript<br>
und FLEX weitestgehend separiert und separat wartbar und verständlich. Daß PHPAC noch immer<br>
hier und dort rotiert, ist ein Beispiel für das erstaunliche Beharrungsvermögen von Anwendungen,<br>
die man irgendwann mal zum Laufen gebracht hat und dann lieber nicht mehr dran rührt. Wenn aber<br>
doch, dann gibt's Unvorhersehbarkeiten, wie Ihr Exempel mal wieder zeigt.<br>
<br>
> <span style=" font-family:'arial';">ps: wie ich darauf komme?<br>
<span style=" font-family:'courier new';">> ich habe höllischen ärger mit einem professionellem differ(auch<br>
> merger) gehabt, er hat mir wertvolle dateien zerschossen, aus der<br>
> codepage-windows-ansi hat er alles ungefragt in eine utf8-datei<br>
> umgeschrieben. UND: was höher decimal 128 in ein "?" umgewandelt!<br>
<br>
Solche Gerätschaften kann man allenfalls, wie z.B. auch PHPAC, als möchtegern-professionell<br>
bezeichnen! Besser Finger weg von sowas.<br>
<br>
B.E.<br>
</td>
</tr>
</table>
</body></html>