Dse Probleme
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Auf dieser Seite können Probleme in der Verwendung des DseWiki beschrieben werden.
Siehe auch /BehobeneProbleme, DseAnregungen, SupportWiki:WikiAnregungen, SupportWiki:WikiProbleme.
| Inhaltsverzeichnis dieser Seite | |
|
|
Suche über Titel-Link einer Unterseite klappt nicht | |
Wählt man auf der Seite GregorRayman/Exceptions oben den Titel-Link, wird mit "Keine Seite gefunden." geantwortet. Die Seite ist aber mehrfach verlinkt.
- Ja, danke für den Fehlerbeschreibung. Die ausgeschriebenen Verlinkungen sind vorläufig zur Not über Volltextsuche zu finden DiesesWiki:search=GregorRayman/Exceptions . Das Problem muss ich mir anschauen, hängt sicher mit Umstellung auf die hierarchische Struktur und Linkstrategien zusammen. Danke nochmal. -- HelmutLeitner
Nicht vollständig in Google indiziert | |
Wir sind mit diesem Wiki in Google anscheinend nicht vollständig indiziert, z. B. liefert die Suche /"bjarne stroustrup" "schrieb das buch"/ (derzeit, 27. November 2003) keinen Hinweis auf die entsprechende Seite dieses Wikis. (Hier jetzt absichtlich kein Link. ;-)
Vielleicht hat jemand Ahnung, wie man das ereichen kann ...
(Vor längerer Zeit meinte mal jemand, wir wären recht vollständig indiziert, siehe DseWikiImGoogle.)
- Mmmh, die Wege des Google sind unergründlich. Ich habe hauptsächlich aus den vorhandenen Seitenzahlen geschlossen, dass die Indizierung einigermaßen vollständig sein dürfte. Hatte aber auch schon immer Probleme mit der Seite EKEIDP, die ziemlich populär ist, auch jeder Menge Links hat, die darauf zeigen, aber im Google nicht zu finden ist. Keine Ahnung warum. Google kommt an sich alle 4-5 Wochen und klappert "alles" ab. -- HelmutLeitner
Stand 23. Januar 2004: Zwar liefert Google bei /"bjarne stroustrup" "schrieb das buch"/ auch weiterhin nicht die Stroustrup-Seite, dafür aber spaßigerweise immerhin diese Stelle hier. (Experimentierhalber linke ich jetzt: KategorieSoftwareGuru, die mittelbar auf die Stroustrup-Seite führt. Allerdings keine Ahnung, ob die Google Engine diese berechnet werdenden Links verfolgt bzw. verfolgen darf.)
Interessantes um Registrierte Seiten einer Domaine im Google rauszufinden:
site:www.wikiservice.at und eventuelle suchbegriffe sucht nur seiten diese domaine -- FranzWieser
Stand 22. Januar 2004: Die entsprechende Seite wird gefunden.
Klammern in Quelltexten | |
Manchmal kommt Wiki mit den eckigen Klammern in nicht klar. Im folgenden Beispiel musste ich
die Klammern verdoppeln, damit ein Teil des Quelltextes nicht ausgeblendet wird:
| def quicksort(a):
if not a: return []
return quicksort([x for x in a if x < a[0]]) + [a[0]] + quicksort([ [x for x in a[1:] if x >= a[0]] ])
#im 2. quicksort-Aufruf ist ein Klammerpaar zu viel, aber Wiki zeigt es sonts nicht an |
|
|
Änderungen/Korrekturen | |
Siehe ÄnderungOderKorrekturDiskussion
Cache | |
Wenn man die Editierseite anfordert (action=edit), schickt AFAICS der HTTPd keinen No-Cache-Header mit ("Cache-Control: no-cache" oder "Cache-Control: max-age=0", AFAIK). Gibt Probleme mit HTTP-Proxies, die dann diese Seite evtl. nicht neu vom Server anfordern. Ist das beabsichtigt?
- Du meinst, dass nach dem Editieren dem Benutzer u.U. auf diese Weise die alte Seite - ohne seine Änderungen - angezeigt wird?
Genau. Folgendes Szenario:
(Voraussetzung ist, dass ich den Browser so konfiguriert habe, dass ein Proxy-Server benutzt wird)
Ich rufe "Ändern" auf einer Seite auf und bekomme das Textfeld angezeigt
Beim Aufruf der Seite hat sich der Proxy-Server deren Inhalt gemerkt ("gecached"), d.h. er hat die Seite in einem internen Zwischenspeicher abgelegt (dafür sind Proxies da)
Wenn ich nun später erneut in derselben Seite "Ändern" aufrufe, liefert der Proxy-Server die gecachete Seite aus, d.h. mit dem alten Inhalt
- Dieses Problem ist mir nicht bewusst und wenn dieses Problem auftaucht, natürlich auch nicht beabsichtigt. Zur allfälligen Lösung benötige ich aber noch mehr Informationen und am besten jemanden der das Problem sehen und die Behebung kontrollieren kann. -- HelmutLeitner
Dasselbe Problem scheint auch bei anderen Seiten aufzutreten.
Die Abhilfe besteht darin, dass der Webserver dem Proxy-Server mitteilt, dass eine bestimmte Seite nicht zwischenspeichern soll. Das geschieht dadurch, dass der Webserver mit der Seite eine spezielle Headerzeile mitschickt, die wie erwähnt entweder
"Cache-Control: no-cache" oder "Cache-Control: max-age=0" lautet. Seiten, die sich praktisch ständig ändern (so wie diese hier), sollten eigentlich immer eine solche Zeile enthalten. Muss im Webserver so konfiguriert werden.
- Da muss ich mich jetzt schlau machen (Apache). Lieber würde ich via Perl jeder Wiki-Seite explizit so eine Zeile mitschicken. Das Einzige, was ich im CGI-Modul sehe, ist aber ein push(@header,"Pragma: no-cache") if $self->cache();. Möglicherweise bewirkt das etwas ähnliches. -- HelmutLeitner
Ja, "Pragma: no-cache" bewirkt dasselbe (ist rückwärtskompatibel zu HTTP 1.0). Mit dem Perl-CGI-Modul für Apache kenne ich mich nicht aus.
- Wie sieht es jetzt bei dir aus? Derzeit ist $cgi->header(-Cache_control => 'no-cache', -pragma => 'no-cache') aktiviert. --hl
Ein ähnliches Problem hatten wir letztens auch. Offensichtlich werden die Headerzeilen von diversen Produkten sehr unterschiedlich ausgewertet - interessanter Weise machen nicht nur ProxyServer? Probleme, sondern z.B. auch der InternetExplorer. Um auf der sicheren Seite zu sein, haben wir schließlich zusätzlich zu 'Cache-Control: no-cache' und 'Pragma: no-cache' auch noch 'expires: -1441' hinzugefügt, sowie das ganze über MetaTags? nochmal direkt in die Seiten eingefügt (also z.B. <META HTTP-EQUIV="expires" CONTENT="-1441">). -- IljaPreuß
Es hat zuletzt Probleme mit den no-cache Optionen in Zusammenhang mit Formularen gegeben, sodass ich kurzfristig gezwungen war, diese zu deaktivieren. Möglicherweise muss ich dieses Problem noch einmal von vorne aufrollen und entweder eine Wiki-spezifische oder Benutzer-spezifische Lösung finden. Wer mit der aktuellen Situation Probleme hat, bitte noch einmal hier deponieren. -- HelmutLeitner
Style | |
In diesem Wiki führt der vorgegebene Style für besuchte Links auf meinem Monitor dazu, dass diese sich kaum von normalem Text unterscheiden. Warum muss denn ein Style vorgegeben sein? Was spricht dagegen, die Default-Styles, die der Benutzer in seinem Browser eingestellt hat, zu respektieren? -- HelmutEnckRadana
- Da könnte man sicher einen Kompromiss finden. Oft führt das Design eines Wiki dazu, dass der Eigentümer auch eine bestimmte Farbauswahl (HTML BODY-Tags TEXT, LINK, VLINK, ALINK) vorgibt. Wenn man darauf verzichtet und bei einer Demo auf einem Fremdgerät oder bei einem Neubenutzer führt dessen Einstellungen zu einer ganz anderen Optik, dann löst das keine Begeisterung aus. Was ich mir aber gut vorstellen kann, ist das optionale Abschalten dieser Tags in den Benutzer-Einstellungen. Wäre das für dich akzeptabel? -- hl
- Optimal! -- her
Zählen der Änderungen | |
In den Diskussionen der letzten Tage ist mir aufgefallen, daß die Autoren die Anzahl der Änderungen mitnehmen also
Wird bei der nächsten Änderung von jb zu
Ist das so beabsichtigt? Ich bin etwas verwirrt, weil mir das bis jetzt nicht in der Art aufgefallen ist.
- Na ja, ob beabsichtigt, da will ich mich nicht festlegen. :-) Jedenfalls ist es die Anzahl der Änderungen des jeweiligen Autors an dem betreffenden Tag. Irgendjemand anderer hat auch schon mal gemeint, es wäre eine ziemlich überflüssige Information. Soll ich sie wegnehmen? -- hl
- Nein. Wenn man das angreift sollte man sich zuerst einmal ein paar AnforderungsGeschichten zurechtlegen, was dort wirklich interessant wäre.
Suche | |
[Langsam krieg ich ja schon ein schlechtes Gewissen, weil ich dauernd hier schreibe.]
Wenn man CharacterCode0166 einsetzt, interferiert das mit der Suchfunktion:
- TestMit0166 (Test¦Mit0166)
Sucht man jetzt nach "TestMit0166" (also ohne ¦ ) so scheint diese Seite nicht auf.
Mir ist bewußt, daß das kein triviales Problem ist, wollte es aber hier einfach dokumentieren.
Siehe InterWebLinks/Erweiterungsvorschläge
Weil es mit oben gerade aufgefallen ist: Rein gefühlsmäßig sollte bei http://linuxwiki.de/%s wohl vor dem '¦' die URL beendet werden.
- Wäre natürlich. Da müsste man aber den Chracter 166 zu einem verbotenen Zeichen in Urls machen. -- hl
- Ist der '¦' überhaupt in URLs erlaubt?
- Ich habe keine Ahnung, deswegen bin ich vorsichtig. -- hl
- Gesehen habe ich ihn noch nicht, notfalls kann er als %A6 kodiert werden. Ich seh' mich mal in den relevanten RFCs um.
Aus RFC1738:
- Octets must be encoded if they have no corresponding graphic character within the US-ASCII coded character set, if the use of the corresponding character is unsafe, or if the corresponding character is reserved for some other interpretation within the particular URL scheme.
Ich denke da 166 nicht in US-ASCII (>127) sollte er so oder so kodiert werden.
- Na ja. Das gleiche gilt für Umlaute. Und auch das wird nicht einheitlich gehandhabt. -- hl
- Abgesehen von den zugrunde liegenden philosophischen Aspekten von VereinheitlichungUndStandards, kommt im gesamten DseWiki "http:\S*¦" genau einmal (nämlich hier) vor.
Vorschau | |
Bei der Vorschau nach dem Editieren werden Links nur teilweise als solche formatiert.
- Hallo, Mister Unbekannt! Danke für den Hinweis. Das DseWiki läuft derzeit auf der Entwicklungsversion (siehe FractalWiki:action=HomePage) und da hatte sich eine Unsauberkeit eingeschlichen. Sie sollte jetzt behoben sein. -- HelmutLeitner
Code | |
Die Darstellung von Code-Elementen unterscheidet sich von Browser zu Browser
deutlich. Um beispielsweise mit dem Konqueror eine nicht verunstaltete Darstellung
zu bekommen muss der Quelltext mit höchstens 50 Zeichen Breite formatiert sein. Das
passt auch recht gut zu dem eingestellten width=50. Für Benutzer von beispielsweise
Mozilla belibt aber unverständlich, warum der Autor Code so "schmal" formatiert.
Dafür fügt Mozilla mit \\ abgeschlossene Zeilen einfach wieder zusammen, was, wenn der
\\ auch noch verschwinden würde, wohl ein gute Lösung wäre. Der \\ bleibt aber
stehen, womit der angedeutete technische Zeilenumbruch als Syntaxfehler
erscheint.
Schrägstrich | |
Lt. Duden wird ein / nicht mit Leerzeichen umschlossen. Es heißt also C/C++ und nicht C / C++. Die Wiki-Software interpretiert den / ohne Leerzeichen ziemlich oft als Ordnerzeichen. Beispiel: Bla/Bla.
- Ja, leider. Macht auch bei manchen Textautoren ziemlich viele Probleme (nicht im DseWiki). Client/Server wäre ein Beispiel. Zwei Alternativen gäbe es:
- (1) Entweder die Links nur bei vorhandener Hauptseite als Fragezeichen-Edit-Link zu realisieren, oder
- (2) für diese Links eine CamelCase-Seite vor dem Schrägstrich zu verlangen. Beides kann auch verwirren, deswegen konnte ich mich noch zu Nichts entschließen.
- Was erscheint plausibler? -- HelmutLeitner
- Ich habe mal Variante (1) implementiert. -- HelmutLeitner
- Variante 1 finde ich in Ordnung. Allerdings erscheinen die betreffenden Wörter noch bei den verlangten Seiten. Ist das beabsichtigt? -- EnricoHüttig
- Nein, das ist nicht beabsichtigt. Es kommt daher, dass ich nur den Link fürs Neuanlegen unterdrücke, zu einer gleichnamig vorhandenen Seite aber den Link herstelle. Nicht konsistent, wird behoben. Danke fürs Fehler-Reklamieren. -- HelmutLeitner 5. Oktober 2004 12:41 CET
- Sollte jetzt behoben sein. -- HelmutLeitner 5. Oktober 2004 12:57 CET
Warum werden Links hier nicht genauso gehandhabt, wie in den anderen Wikis (mit eckigen Klammern). Mir ist z.B. aufgefallen, das VisualBasic und VisualBasic für Applikationen auf den gleichen Link (VisualBasic) verweisen, obwohl es ja nicht das gleiche ist. Aber soll man nun zur Unterscheidung VisualBasicFürApplikationen? schreiben? -- RitaBock?
- Hi Rita, ich weiß nicht genau, was to meinst. Geht es um CamelCase vs. explizite Links? Oder darum Links mit anderem Titel zu versehen? Geänderte Titel können so geschrieben werden, meist sinkt aber dabei die Transparenz. -- HelmutLeitner
Unbeabsichtigte Unterseite | |
Wie bekomme ich aus SpracheSmalltalk/Portabilität einen Link auf SoftwarePortabilität? Irgendwie lande ich immer bei SpracheSmalltalk/SoftwarePortabilität.
- Ich hab die leere Seite SpracheSmalltalk/SoftwarePortabilität zuerst gelöscht, dann linkt die Seite automatisch auf das Top-Level. Andernfalls Top:SoftwarePortabilität.
- Die Reihenfolge, in der nach möglichen Seiten für das Linken gesucht wird, ist in der Konfigurationsvariable
| Variable AutoLinkStrategies: |
B;T |
|
|
- definiert. Siehe SupportWiki:AutoLinkStrategies (B=Brother=gleiche Ebene, T=Top). -- HelmutLeitner
Sehr kaputtes Textparsing | |
Diese Zeichen stören den Aufbau der Seite bei der Vorschau gewaltig. Man beachte vorallem den untersten Teil der Seite (Nach Zusatzfunktionen):
''foo
''
Links auf Dokumente mit der Endung .PDF werden anders dargestellt als solche auf *.pdf. Beispiel siehe ModelViewPresenterPattern.
/BehobeneProbleme
KategorieDseWiki KategorieWikiProbleme
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 14. März 2008 15:17 (diff))