11 Jun
2003
11 Jun
'03
9:27 p.m.
Hallo Mike,
Nein, der Benutzer lädt einfach seine Bookmark-Datei rauf und diese
wird dann geparst. Bei Safari handelt es sich dabei um ein XML-File
(im Apple-eigenen und nicht unbedingt für parsen geeigneten .plist -
Dialekt). Noch ist das ganze ein wenig roh, wollte einfach mal
XML-Parsing lernen. Im Moment wird alles in die selbe Kategorie
geschmissen; falls die Links im Browser in einem Unterordner sind,
sollte sich das in der LinkCollection auch wiederspiegeln.
Das tönt ja viel eleganter als mit einem platformspezifischen
Apple-Script. Ist im Endeffekt wohl auch einfacher für den Endbenutzer.
Grüsse
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Nun, ein einfacher Ansatz zum Feedback ist bereits in
der Action
PageEdit drin. Dort gibts die Instanzvariable exception, die einen
Wert erhält falls das Parsen der Benutzereingabe scheitert. Falls
exception nun nicht nil ist, wird sie mit PageEdit >> renderError in
der aktuellen Seite ausgegeben.
Ach ja, den habe ich vergessen :-)
Dies könnte man in dem Sinne erweitern, dass in den
Callbacks einer
Aktion die Eingabe überprüft wird; ist sie gültig wird die Aktion
ausgeführt, ist sie nicht gültig wird die Variable exception gesetzt
und die Seite neu geladen -> renderError zeigt dann die entsprechende
Fehlermeldung an.
Zuerst die Frage des Designs und des Layouts: Wo möchtest Du
renderError denn anzeigen? Man könnte es zum Beispiel gerade nach dem
Header einfügen, wäre das aber nicht eine Einschränkung?
Zum technischen Teil versuche ich kurz das gelesene zusammenzufassen,
nur um sicherzustellen, dass wir uns verstehen: Du möchtest also
renderError in der Klasse Action implementieren und diese Methode dann
ausführen, wenn während dem Verarbeiten der Callbacks eine Exception
auftritt?
Auf den ersten Blick, scheint mir das eine sehr vernünftige Lösung zu
sein. Muss mir aber noch überlegen, ob das keine unnötigen
Einschränkungen mit sich bringt und was passieren soll, wenn ausserhalb
der Callbacks eine Exception auftritt. Ausserdem muss sichergestellt
werden, dass keine Benutzereingaben verloren gehen und dass bei
mehrfachen Exceptions keine Loops entstehen.
Die Verantwortlichkeit zum Überprüfen der
Benutzereingabe liegt bei
diesem Vorschlag bei der Action und nicht bei Structure - nicht
unbedingt der richtige Ort.
Wenn auch die Structure eine Exception mit einem netten Fehlertext
wirft, spielt das ja keine Rolle von wo wir die Information erhalten.
P.S. Jetzt kannst du in der LinkCollection deine
Safari - Bookmarks
importieren ;-)
Genial, dass muss ich gleich ausprobieren. Machst du es mit einem
Apple-Script? Ist der Source-Code dazu in deinem Package?