OpenOffice.info

Hallo zusammne

ich hab keine Idee, wie ich das machen kann, aber die Hoffnung stirbt zuletzt:

Gibt es über Umwege die Möglichkeit einer Zelle eine Änderungsdatum anzufügen. Dokumentenweit geht sowas ja.

Warum ich das für möglich halte:

Wenn man Änderungen aufzeichnet, dann seht man ja auch, dass ein anderer Autor was geändert hat.

Ideal wäre also eine Möglichkeit zu sehen, welcher Autor zu welchem Zeitpunkt Änderungen an einem Objekt (z.B. Zelle) vorgenommen hat.

Dabei ist nur wichtig, wann die letzte Änderung an z.B. der Zelle gemacht wurde (und nicht was geändert wurde - das ist sonst zu verwirrend).

Anwendungsfall: Team teilt sich die Erarbeitung eines Dokumentes und will nicht jede Änderung besprechen, sondern nur direkt sichtbar machen, wer wann wo die letzte Änderung gemacht hat. Man könnte das auch Manuell machen - ist aber der Masse wegen etwas umständlich.

Ideal wäre also eine Möglichkeit zu sehen, welcher Autor zu welchem Zeitpunkt Änderungen an einem Objekt (z.B. Zelle) vorgenommen hat.

Das ist doch aber über die Änderungsverfolgung möglich (Bearbeiten-Änderungen-Aktzeptieren oder verwerfen... die nicht nur Autor der Änderungen sondern auch deren Position/Zelle anzeigt.

Oder um was geht es sonst bzw. was verstehe ich falsch?



Gruß
Stephan

Hallo Stephan

danke erstmal fürs Feedback.

Oder um was geht es sonst bzw. was verstehe ich falsch?

Ich will nur wichtige Änderungen und das wahlweise sichtbar machen. Wenn das Lektorat nur Rechtschreibung korrigiert ist das völlig uninteressant und der Masse wegen verwirrend. Da muss jeder Entwickler ja jedes mal die ganze Datei (40 Seiten) anschauen.
Ein Header mit Änderungsprotokoll wäre eine Alternative.

Mir würde aber eine Möglichkeit gefallen, die ähnlich funktioniert, wie die Feldbefehle für die letzte Änderung am Dokument.

Ich vermute mal, dass man dafür ein Plugin entwickeln müsste? Oder kann man sich das mit den Feldbefehlen zusammen basteln - und ich hab das einfach nur nicht gefunden?

Äh, ich sehe gerade wir sind hier bei Writer. Geht es vielleicht um eine Writertabelle und nicht um eine Calc-Tabelle (wie ich bisher annahm)?


Gruß
Stephan

ja genau

Das Dokument enthält viele Einzeltabellen, in denen die Zellen sporadisch geändert werden. Wenn man die aktuelle Spezifikation der Entwicklerversion (des Projektes), die sich eben on demand ändern kann, prüfen will, dann muss man eben schnell sehen, dass und wann es eine Änderung gab, die man evtl. noch nicht wahr genommen hatte.

("man" ist der Entwickler )

Oder kann man sich das mit den Feldbefehlen zusammen basteln - und ich hab das einfach nur nicht gefunden?

Nein, das sicher nicht. Aber beantworte erstmal meine letzte FRage, falls es um Calc geht findet sich vielleicht jemand der nachrecherchiert wie man an entsprechende Infos per Makro rankommt, 'aus dem Hut' weiß ich das nämlich auch nicht.

(Die INfos stehen, zumindest bei ods-DAteien, in der content.xml, was aber für die Makroüberlegung keine wesentliche Info ist)


Gruß
Stephan

Stephan hat geschrieben:Äh, ich sehe gerade wir sind hier bei Writer. Geht es vielleicht um eine Writertabelle und nicht um eine Calc-Tabelle (wie ich bisher annahm)?

Ja - genau

Oder kann man sich das mit den Feldbefehlen zusammen basteln - und ich hab das einfach nur nicht gefunden?

Nein, das sicher nicht.

Ok - dann brauch ich den Weg nicht weiter verfolgen.

content.xml

OK - sowas gibts ?
(dann sicher auch für Odts)

Hast du da evtl. einen Link parat, wo dieser Mechanismus beschrieben ist? (kann ja sein)
Evtl. baue ich dann einfach "meine erste OOO-Extention"

Hast du da evtl. einen Link parat, wo dieser Mechanismus beschrieben ist? (kann ja sein)
Evtl. baue ich dann einfach "meine erste OOO-Extention"

Also - ich hab die Datei mal mit TextWrangle (Mac OS X) geöffnet und gesehen, dass ODT-Dateien ein XML-Container sind.

Nach genauerem Untersuchen der XMLs steht fest: Kann nicht gehen, da die meta.xml nur Dokumentenweit verwendbare Infos speichert.

Ein möglicher Lösungsweg wäre:

Zellen komplett in Datenbank speichern und jedes mal ein Timestamp rein packen. Die kann man dann ja mit Datenbankfeldern anzeigen lassen.

Mal schauen, ob ich mir die Arbeit mache, das ganze Dokument in eine Datenbank zu überführen... wäre sinnvoll, da es auch anderweitig einsetzbar ist.

Aber damit wäre die Lösungsfindung hier mal abgeschlossen - die Idee soll für die Nachwelt sein, wenn jemand sein Dokument erst noch plant...

Nach genauerem Untersuchen der XMLs steht fest: Kann nicht gehen, da die meta.xml nur Dokumentenweit verwendbare Infos speichert.

Hä? WAS kann nicht gehen?

Die content.xml enthält im Falle einer *.odt-Datei und einer normalen Texttabelle in der Tabellenzelle einen ID-Verweeis auf die entsprechende Änderung und zentral den Inhalt der ID (insbesondere also NUtzer und Änderungszeit):



Gruß
Stephan

Hä? WAS kann nicht gehen?

Die content.xml enthält im Falle einer *.odt-Datei und einer normalen Texttabelle in der Tabellenzelle einen ID-Verweeis auf die entsprechende Änderung und zentral den Inhalt der ID (insbesondere also NUtzer und Änderungszeit):

OK - ich hab im TextWrangler keine Zeilenumbrüche in der Content.xml gehabt. Wegen Usability also fehlerhaft interpretiert...
Edit: Wobei... ich hab grade nochmal geschaut... kann es sein, dass die Daten nur drin stehen, wenn man Änderungen aufzeichnet? (vermutlich)

Danke für dein Engagement, das nochmal zu analysieren!

Nachdem ich mich jetzt ja eigentlich schon von der Idee verabschiedet hab und eine Datenbanklösung forciere (weiter verwendbarkeit) ist das natürlich etwas blöde jetzt, dass du dir die Arbeit gemacht hast und nix wird draus.

Evtl. gibts ja doch noch ne Chance, dass ne Lösung für die Nachwelt draus wird.

Hast du Ahnung davon, wie man da jetzt ran gehen würde, daraus jetzt eine Lösung für ALLE zu machen?

Ich kann mir folgende Varianten vorstellen:

(Alles unter der Vorraussetzung, Änderungen werden aufgezeichnet, aber nicht angezeigt)

1) Einfügen -> Objekt -> Plugin: IRGENDWIE (kein Plan) ein Plugin bauen, dass die content.xml parsen tut und als Übergabeparameter die "changed-region te t:id" bzw. die "xml:id" bekommt. Als Ausgabeparameter wäre dann "dc:date" in formatierter Form in ein Feldbefehl umzusetzen. Genau wie das Dokumentendatum wird das Feld bei jedem Speichern prüfen, ob sich ein neuer "dc:date" der "changed-region te t:id" ergeben hat. Wenn ja, wird es angezeigt. Vermutlich wird der "text:cahnge-region.."-Block gelöscht, wenn Änderungen bestätigt wurden und wenn sich Änderungen häufen ohne bestätigt zu werden, gibt es mehrere solche Blöcke... das heißt ein Plugin müsste die jeweiligen "dc:date"-Nodes vergleichen und das neuste anzeigen.

2) Extras -> Macro -> (NeoOffic) OOO-Basic: http://wiki.services.openoffice.org/wik ... ce.org_API
Hier dann direkt auf das Objekt und den Node zugreifen, den Rest wie bei 1)

Wenn ich mir das so überlege, könnte Version 2 an einem netten Abend realisierbar sein.

Noch Tips für die Realisierung? - Ich kann aber nicht versprechen, ob ich das wirklich die Woche noch anpacke. Abgabetermine...

OK - ich hab im TextWrangler keine Zeilenumbrüche in der Content.xml gehabt. Wegen Usability also fehlerhaft interpretiert...

Du hast nichts von Conternt.xml geschrieben sondern WEIL in der meta.xml nur dokumentweit verwendbare Infos stehen könne es nicht gehen:

Nach genauerem Untersuchen der XMLs steht fest: Kann nicht gehen, da die meta.xml nur Dokumentenweit verwendbare Infos speichert.

Wie man zu einer solchen Aussage kommt indem man eine völlig andere Datei 'fehlinterpretiert' ist mir nicht so ganz klar.

kann es sein, dass die Daten nur drin stehen, wenn man Änderungen aufzeichnet?

ja, ist so.

Hast du Ahnung davon, wie man da jetzt ran gehen würde, daraus jetzt eine Lösung für ALLE zu machen?

Nein, nicht konkret, weswegen ich ja bereits schrieb das die Kenntnis das die Dinge in der Content.xml stehen nicht direkt nützt, da sie aber da sind muß man einen Weg finden per Makro dranzukommen.


Gruß
Stephan

Du hast nichts von Conternt.xml geschrieben sondern WEIL in der meta.xml nur dokumentweit verwendbare Infos stehen könne es nicht gehen:

Nach genauerem Untersuchen der XMLs steht fest: Kann nicht gehen, da die meta.xml nur Dokumentenweit verwendbare Infos speichert.

Wie man zu einer solchen Aussage kommt indem man eine völlig andere Datei 'fehlinterpretiert' ist mir nicht so ganz klar.

Jetzt mal halblang... das hättest du dir auch sparen können.

Aber um die Sache aufzuklären: Ich hab mir alle Dateien angeschaut und dabei im Eifer des Gefechts einfach alles in einen Topf geschmissen.

Nein, nicht konkret, weswegen ich ja bereits schrieb das die Kenntnis das die Dinge in der Content.xml stehen nicht direkt nützt, da sie aber da sind muß man einen Weg finden per Makro dranzukommen.

Gut - mittlerweile gehe ich davon aus, dass entweder ich, oder ein zukünftiger Leser der ein ähnliches Problem hat, wird dies hiermit nutzen/verwerten/lösen können:

2) Extras -> Macro -> (NeoOffic) OOO-Basic: http://wiki.services.openoffice.org/wik ... ce.org_API
Hier dann direkt auf das Objekt und den Node zugreifen