Ich habe heute wieder etwas dazugelernt:
Will man mit Struts auf ein Java-Bean zugreifen, darf das Bean keine gleichnamigen Methoden haben.

Folgendes hatte ich versucht:
Eine Java-Bean hat zwei Methoden.

1. getNoteShort()
2. getNoteShort(length)

Wie eindeutig sichtbar ist, ist die zweite Methode parametrisiert.
In einer JSP-Seite wollte ich nun auf die erste Methode zurückgreifen, was ich folgendermassen mache:
< bean:write name="beanname" property="noteShort" />

Und was passiert? Nix!
Wieso? Scheinbar ist sich struts nicht sicher, welche von beiden Methoden gemeint ist, da es ja auch keine Möglichkeit gibt dem Aufruf einen Parameter mitzugeben.

Also habe ich kurzerhand die zweite Methode umbenannt und schon läuft alles reibungslos.

Man mag es ja kaum glauben, aber für meinen heutigen Ärger über Browser und ihre Unzulänglichkeiten ist mal nicht der IE oder der MacMoz schuld - sondern der Firefox!

Allerdings halte ich zugute, dass das Problem nicht auf Windows sondern nur auf dem Mac auftrat ;)

Folgendes Problem stellte sich mir:
Ein Div hat die CSS-Eigenschaften visibility:hidden, overflow:auto sowie eine feste Größe und viiiel Inhalt.
Das erwartete Verhalten, sollte dieses Div per Knopfdruck (Javascript, das die visibility-Eigenschaft ändert) einblenden, und den Inhalt mit einem Scrollbalken im Div zugänglich machen.

Soweit, so einfach und schick.

Im Firefox auf dem Mac allerdings waren immer Scrollbalken im Weg. Diese wurden einfach immer angezeigt. Egal ob das Div versteckt war oder nicht. Das nervt. Lange hats gedauert, bis ich herausgefunden habe, dass das keine Unzulänglichkeit von mir, sondern vom Firefox ist.

Der Workaround ist so simpel wie naheliegend:

Man benutze statt der Eigenschaft visibility einfach display
ODER (und das fand ich besser)
Man setze im Javascript zusätzlich die Eigenschaft overflow. Für das versteckte Div muss sie "overflow:hidden" heissen (keine Scrollbalken mehr - yeah!). Natürlich muss man sie dann wieder für das sichtbare Div auf "overflow:auto" zurücksetzen.

Vielen Dank an das Selfhtml-Forum für die schnelle Hilfe!

Schon früher habe ich davon berichtet, dass ich mit Mozilla 1.2 und 1.3 für Mac-Os (im folgenden MacMoz genannt) auf dem Kriegsfuss stehe... und heute ist mal wieder so ein Tag, an dem ich dieses Hassgefühl ganz besonders arg spüre!

Ich habe ein Javascript gebastelt, das einen Upload-Button versteckt und einen Löschen-Button hinzufügt, wenn jemand über den (neuen und schickeren) Upload-Button eine Datei zu dem Formular hinzufügt.

Alles schick - alles gut! Funktioniert sogar im IE ;)

Das Problem an der Sache - jedesmal wenn sich ein Textfile names "fakefile" ändert (immer dann wenn eine neue Datei ausgewählt wurde), soll ein weiterer Löschen-Button und ein neuer Hinzufügen-Button auf der Seite dargestellt werden.
Findige Javascript-Kenner werden sich natürlich denken, dass der Eventhandler "onchange" genau das wäre was ich brauche... Weit gefehlt meine Damen und Herren ;)

Ein Fileupload (ein ganz normales input-Element des Typs "file") wirft im MacMoz kein "onchange"-Event, wenn eine Datei ausgewählt wurde und das dazugehörige Textfeld sich ändert !

*arg!*
lina-

Tja - meine "Hoffnung" hat sich bestätigt... es war nur die Festplatte, die meinem Laptop diese seltsamen Geräusche entlockte.
Dummerweise ist diese jetzt so kaputt dass ich nicht mal mehr an die Daten rankomme :( Somit sind nun alle email adressen weg, alle mails, alles was grad so in Bearbeitung war *schnief*.
Und - was absolut tragisch ist: mein Spielstand! *schluchz*
Aber wenigstens ist der Spieleabend Freitag Nacht gerettet, da mein Mann bereits eine neue Platte eingebaut hat :)

tragisch...
lina-

Hilfe! Schon vorgestern abend habe ich seltsame Geräusche von meinem Laptop vernommen. So ein komisches Rattern ab und an - nur selten.
Wie das ja oft bei Laptops so ist, werden die gerne zu heiss, weil ich mit meinen Knien die Lüftungsschlitze verstopfe *g* Ok.. daran lags aber auch nicht. Lüfter tut.
Gestern abend nun dachte ich mir kurzzeitig "Diese Geräusche hab ich bei dem Spiel noch nie gehört... " Bis mir schlagartig klar wurde, dass dieses Geräusch nicht vom Spiel sondern vom Rechner kam. Irgendwie hörte es sich an, als ob jemand eine Katze quält - waaaah!
Also hab ich den Rechner erstmal ausgemacht, den einzigen abnehmbaren Deckel runtergenommen und nach dem Lüfter geschaut - alles in Ordnung - nicht mal sonderlich doll verstaubt.
Nun ja - heute ist der Laptop in Behandlung und ich hoffe inständig dass es "nur" die Festplatte sein wird, die einen Knacks wegbekommen hat.
Einen neuen Rechner könnte ich mir derzeit nicht leisten :(

hope!
lina-

Dateioperationen mit Java sind ja recht einfach angelegt.
Es gibt nur immer mal wieder Stress und Ärger wenn irgendwo im Programmcode vergessen wurde, ein Stream zu schliessen.
Wie oft musste ich mich schon damit rumplagen, dass die Methode myFile.delete() einfach ein "false" zurückgibt anstatt die Datei ordnungsgemäß zu löschen. Ebendies ist das Resultat eines nicht geschlossenen Streams oder einer im Hintergrund geöffneten Datei.

Man gewöhnt sich an alles :(

Letztens habe ich einen Fehler in einem Programm suchen müssen, den ich selber verzapft habe... Konnte ihn auf meinem Windowssystem aber nicht nachvollziehen. Die Verwirrung war groß.
Schlussendlich (nach vielem Fluchen und Wutanfällen) habe ich gelernt: Auf Unix-Systemen tritt das soeben beschriebene Ärgernis nicht auf ;) Hier können Dateien selbst dann mit delete() gelöscht werden, wenn sie gerade noch geschrieben werden (unter Windows undenkbar). Blöd nur, dass ich mich auf das Windows-Verhalten verlassen habe :/
*kopp aufn Tisch knall*

wieder was gelernt...
lina-