Elexis Property Pages

[marcode]

Eclipse bietet Extension Points für die Verwendung von Properties resp. PropertyPages (cf. http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/preferences_prop_contribute.htm). Das Plug-In at.medevit.elexis.properties in elexis-addons erweitert Elexis um grundlegegende PropertyPages. Properties an sich sind derzeit in Arbeit.

Was bedeutet das? Für ein Element in Elexis von einem bestimmten Type (zB Patient, Artikel etc.) können PropertyPages hinterlegt sein, welche beim Auruf der Eigenschaften für ein solches Element angezeigt werden. Dass folgende Bild zeigt beispielsweise die Eigenschaften eines Patienten:

Sample Property Page

propertypage.png (57.61 KiB) 13128-mal betrachtet

at.medevit.elexis.properties selbst bringt hierbei die PropertyPages Anschrift und Details für den Patienten mit. Wie? Durch den Extension Point handler, der sie nur aktiv schaltet, wenn ein Typ Patient gewählt ist (siehe Elexis developers Mailinglist [PATCH] Deklarativer Zugang zur PatientenListe vom 28.5.2011.

Beliebige Plug-Ins können hierbei weitere PropertyPages contributen, die dann angezeigt werden. Die Property-Page selbst wird plattformspezifisch aufgerufen. at.medevit.elexis.properties bringt allerdings die Command-Integration für den Aufruf für ArtikelListe unde PatientenListe mit sich (siehe auch [Elexis-develop] [PATCH] Deklarativer Zugang zum Leistungsblock-Viewer in LeistungenView und CodeDetailView).

Beide angegebenen Patches (4742 und 4812) werden benötigt um die Properties zu integrieren.

Ad request Harry:

Die Definition des Doppelklick-Handlings über Extension Points ist nicht möglich. Man müsste also entsprechend den Aufruf der Propertyies mittels .addDoubleClickListener() an die resp. Viewers hängen. Es ist soweit ich das sehe auch nicht geplant diese über EPs zu machen.

Verfügbarkeit:
Ab heute im Elexis-Addons branch 2.1.5.x; bei Übernahme in andere Branches bitte die Patches nicht vergessen!

All the best, Marco

Dieses Plug-In ist meiner Tochter Anna gewidmet, die am 26.5.2011 12:37 Uhr auf die Welt gekommen ist

[gweirich]

Ich finde das ausgesprochen cool und absolut der richtige Weg. Die vielen "Eigenschaften" und "Detail"-Views sollten mit einer einheitlichen Properties-Vies ersetzt werden.

Allerdings würde ich das lieber in 2.2. statt in 2.1.x sehen, weil eine so grundlegende Designänderung unserem eben erst hart erkämpften Stabilitätsanspruch widerspricht.

Ich kenne das Problem nur zu gut: Man hat eine coole Neuerung die man am liebsten schon gestern eingeführt hätte, aber das breite Publikum stört sich eher an den Neuerungen und den als Seiteneffekte auftretenden Detailstörungen, als dass es die coolness wirklich honoriert. Genau diese Diskrepanz zwischen Entwicklerdrang und Anwender-Stabilitätswunsch hat ja zur Entwicklung der Release-Trains geführt.

Also: Können wir das Konzept strukturiert in 2.2 einfliessen lassen, oder spricht etwas dagegen?

Auch auf diesem Weg noch herzliche Glückwünsche und vergiss nicht, Anna frühzeitig an ihre Aufgabe als Alphatesterin zu gewöhnen. Wie wäre es mit einer iRassel als Geburtsgeschenk?

[marcode]

Hallo Gerry,

danke für die Glückwünsche! Ich verstehe deine Einwände und sehe die Sache so:

Wir müssen bzgl. Stabilität abgrenzen, es handelt sich ja hier um ein neues Plug-In das beliebig eingebunden werden kann, da es ja im Grunde genommen unabhängig von verwendeten Kern ist! Es braucht allerdings zwei Patches, um das Plug-In lauffähig zu machen; diese sind hinsichtlich der Stabilität aber unproblematisch da sie nur folgendes durchführen:

* Sie registrieren den in einer View verwendetene Viewer beim System als Selection Provider.
* Sie registrieren das bei diesem Viewer verwendete Menu als solches beim System damit man Commands deklarativ hinzufügen kann.

Wie du in den Patches sehen kanns, ist das also Code der komplett aus dem Eclipse Projekt stammt, wir können hier uns also auf dessen Stabilität verlassen, bestehende Funktionalität wird dabei nicht verändert oder angepasst.
Ich habe auch div. Szenarien getestet: Ist eine PropertyPage falsch deklariert etc. scheint Sie einfach nur nicht auf, es wird aber kein Fehler geworfen!

Der Hauptteil ist also in einem neuen Plug-In das überall reingehen darf, und die Patches die für die Verwendung notwendig sind sind minimal! In 2.2 würde ich das Komplette Konzept der Properties (also nicht nur die Property Pages! (cf. http://www.eclipse.org/articles/Article ... -view.html) einfliessen lassen, was eine neue Form der Usability mit sich bringt! Hier sind weitreichendere Änderungen notwendig, so dass ich das mit meiner Stabilitäts-ausrichtung nicht mit 2.1 vereinbaren kann, und mich dir voll anschliesse

Die PropertyPages sind eine relativ unkomplizierte und minimal-invasive Adaption um die Anforderungen kurzfristig zu erfüllen! Die vollen Properties gehn da schon einen anderen Weg!

Wenn wir die vollen Propertes in 2.2 reinbringen, sollten wir das strukturiert tun, wie du das eben sagst, und hier sollten wir auch alle Usability Aspekte mit reinbgringen.. dann können wir was ganz cooles bauen

iSchnuller und iNippel sind schon installiert. Ist iRassel schon released, wird das nicht erst in div. Gerüchte-Foren behandelt? *gg*

[gweirich]

Wie du in den Patches sehen kanns, ist das also Code der komplett aus dem Eclipse Projekt stammt, wir können hier uns also auf dessen Stabilität verlassen, bestehende Funktionalität wird dabei nicht verändert oder angepasst.

Dann hab ich es whs. anders verstanden: Für mich ist die Patient-Property ein (durchaus guter!) Ersatz für die PatientDetailView. Ebenso wäre eine Fall-PropertyPage ein Ersatz für die FallDetailView usw.

Das wäre eine Designänderung mit einem gewissen Gewöhnungsbedarf und einer gewissen Fehleranfälligkeit. Einfach nur die von Dir genannten Anpassungen scheinen mir in der Tat unkritisch.

iSchnuller und iNippel sind schon installiert. Ist iRassel schon released, wird das nicht erst in div. Gerüchte-Foren behandelt? *gg*

Stimmt. Wir sollten ohnehin gleich Nägel mit Köpfen machen und iLexis mit dem EFB (Elexis for Babies) Plugin endlich rausbringen, damit man belegen kann, dass das Programm wirklich kinderleicht zu bedienen ist. Musst halt das iPad sabberdicht machen

[marlovitsh]

Ich finde vor allem das Konzept bestechend (!)
Es ist ausserordentlich einfach, irgendwo zusätzliche Infos anzuhängen - entweder im Plugin selbst - oder aber man kann aus irgendeinem Plugin heraus zusätzliche Infos anhängen, so wie man es gerade braucht, einfach so. Coole Sache.
Habs ja vorher schon mal in meinen persönlichen Trunk eingebaut - ging einwandfrei und definitiv ohne Probleme.

Ich stelle mir aber bei einem Doppelclick definitiv vor, dass sich die dazugehörige View öffnet - ich fände da einen Konzeptwechsel irgendwie falsch.
Es wäre auch möglich, die ganze View einfach im Fenster diese anzuzeigen - aber dann bin ich modal gefangen und kann nichts anderes mehr tun - auch nicht sinnvoll.

Die schönere Variante ist da für mich, im Kontext-Menu der Liste die Properties-Anzeige auswählen zu können.
Hier werden dann zusätzliche Infos angezeigt, die sonst nicht oder nur umständlich zu erreichen/einzugeben wären.


Beim iLexis und dem EFB wäre ich dabei - ich könnte mich da mittels Code beteiligen, wenn ich nen Zugang kriege...
...dann gäbe es noch neben iLexis das iLexus (besonders einfach zu bedienendes virtuelles Auto für Babies)

Gruss, Harry

[gweirich]

Ich bin nicht sicher, ob ich Deinen Einwand richtig verstehe. Für mich würde es so aussehen: Man hat eine (in Worten: Eine!) View, die die Properties enthält. Und die zeigt einfach immer die Properties des momentan ausgewählten Objekts (Patient, Termin, Fall, Konsultation, Rezept, whatever).
Das ist nicht modal und braucht weder Doppelklick noch Rechtsklick. Man holt einfach die Properties-View in den Vordergrund, wenn man irgendwelche Properties sehen möchte.

Spricht was gegen diesen Ansatz?

[marcode]

Hey, das is einer der Unterschiede

Properties <-> PropertyPage

Es lässt sich diskutieren, ob bei zukünftigen Versionen der Properties-View einen der Kern-Elemente darstellen wird. Bei konsequenter Nutzung wird sich jedenfalls die Art der Anwendung leicht verändern. Der Properties-View hat aber noch einige interessante Zusatzfunktionen; wir haben hier erst ein kleines Sample am laufen, aber man kann zB die Darstellung eines Elementes "pinnen" und daneben ein neues öffnen um sich Dinge vorübergehend ständig angezeigt zu lassen!

Also meiner Sicht nach Elexis >2.1.x PropertyPages (minimal invasiv, grundlegende Konzepte der Properties werden eingeführt) ... Elexis >2.2.x Properties (wobei PropertyPages natürlich auch dabei sind)

atb,
marco

[marcode]

Mal ein Beispiel zu Properties:

Properties sind "embedded", wenn ich also, wie bei folgendem Pic, ein Element eines bestimmten Typs wähle, kriege ich dazu die durch die Properties definierten Informationen:

Properties

properties.png (50.07 KiB) 13090-mal betrachtet

[marcode]

Das Beispiel für die Extension Points zu Property Pages habts ihr ja, jetzt mal vergleichsweise für die Properties:

Extension Points für Properties

PropertiesExtensionPoint.png (40.62 KiB) 13090-mal betrachtet

[marlovitsh]

Sorry, Gerry, meine Antwort dauerte etwas länger - aber wenn ich die von Marco gezeigten Bilder anschaue,
dann ist dort wohl die Darstellung, so wie ich mir sie eher wünsche sowieso schon gezeigt.

Das Beispiel, das im 2.1.5.x zu bewundern ist, zeigt die Properties in einem Dialog (PropertyPageDialog). Wenn dieser offen ist, dann kann ich nur diesen Dialoginhalt
bearbeiten und nichts anderes in Elexis tun - zum Bespiel noch schnell etwas anderes in einer anderen View nachschauen und gleich zurückswitchen. Deshalb "modal",
was ja heute eher vermieden werden soll.
(Inside MacIntosh, Vol I, Zitat "But, gentlemen, you overdo the mode" - ja ja - ich komme ursprünglich von der Mac-Seite...)
Das wäre für mich zu umständlich und es wäre definitiv ein Rückschritt bezüglich Benutzerfreundlichkeit.

Wenn die Properties aber in einer View angezeigt werden (wie im einen Bild von Marco), dann sind diese Properties genau das, was ich mir vorstelle.
Die Darstellung wird dann über das ganze Projekt sicher einheitlicher und damit vor allem für Neulinge einfacher zu bedienen.
Das wollen wir ja. Wir selber, die uns schon gewisse Dinge gewohnt sind, müssten uns dann etwas umgewöhnen.
Dann wären die PropertyPages irgendwann der Ersatz für die einzelnen Views.
Neues kann ja besser sein!


Wenn diese Properties dann in der Regel als "normale" Views in Perspektiven dargestellt werden, dann finde ich diese "Designänderung" absolut erstrebenswert.


...dann noch zum Doppelclick:

Der Doppelclick in eine Liste muss für mich die "richtige" Detailview öffnen:

PatientenListe -> PatientDetailView (später dann PropertyPage!)
FallListe -> FallDetailView (später dann PropertyPage!)
KonsListe -> KonsView (später dann PropertyPage!)
etc.

Das fehlt uns letztlich noch - nur bei der Kontaktliste ist dies implementiert.
Das sind alles 5- bis 10 Zeiler, die wir leicht einfügen könnten uns gleich zur Verfügung stünden.
Sobald ein einzelnes Teil als PropertyPage zur Verfügung steht, dann muss dort nur minimal etwas verändert werden, und es läuft schon mit der neuen Ansicht.

Ach ja - Marco: das ist/wird ein cooles Teil!

Gruss, Harry