Pickwick81 schrieb am 22. Oktober 2011 19:59
> JustTryIt schrieb am 21. Oktober 2011 18:58
>
> > Wenn man die XPath Ausdrücke auslagert, dann aber nicht in andere
> > Klassen, sondern in Konfigurationsdateien die dann in den Speicher
> > geladen werden.
>
> Klassen haben aus meiner Sicht aber den Vorteil, dass man Variablen
> für gemeinsame Bestandteile zur Verüfgung hat. In meinem Fall
> beispielsweise ist der Anfang bestimmter XPath-Ausdrücke immer
> gleich.
Das kannst du auch bei Konfigurationsdateien haben.
basic.root=/businessData/organisation[@name='ACME']
organisation.employee.list=${basic.root}/employees/employee
> An Konfigurabilität habe ich auch gar nicht gedacht, selbst
> für einen normalen Admin ginge mir das zu weit. In meinem Fall
> zumindest muss da eigentlich nur ein Entwickler ran.
Richtig, eine Vereinfachung für Endanwender soll das gar nicht
darstellen. Nur eine Trennung zwischen Ausdrücken und Code. Und mit
Konfigurationsdateien kannst du z.B. während der Laufzeit des
Programms Wartungsarbeiten vornehmen, in dem du z.B. Ausdrücke
korrigierst, und dann die Datei neu einlesen lässt. Kann man machen,
wenn Bedarf besteht.
> > Kann man machen, aber man verliert leicht den
> > Kontext, was sich aber durch aussagekräftige und hierarchische Knoten
> > abfedern lässt (oder man verwendet z.B. die Properties aus Apache
> > commons, die sind bereits hierarchisch).
>
> So habe ich das bei mir auch, zum Teil bildet man dann aber
> Klassensturkturen unnötig doppelt ab, finde ich.
OK, wenn du das spiegeln willst, wären Annotations wohl nicht
schlecht.
> > Eine Alternative wäre es die XPath Ausdrücke
> > in Annotations zu verpacken - ähnlich wie das bei JPA mit den Queries
> > gemacht wird.
>
> Wie sieht das genau aus? Und wo soll der Vorteil ggü. einer eigenen
> Klasse sein, wenn man "Dinge" beachten muss?
@XPathQuery(name="getOrganisationByName",query="/businessData/organis
ation[@name=$NAME]")
public class Organisation {
...
}
Vorteil: Steht nicht im Fließtext, aber dort wo es gebraucht wird.
> > Probleme beim direkten einbetten in den Code sehe ich beim
> > Refactoring: Wenn man jedesmal die Ausdrücke kopiert, dann ist das
> > ändern aller identischen Schnipsel mühsam.
>
> Dachte ich mir auch, nur sieht man dafür dann aber auch eher, wie
> weit man bei Codeänderungen gehen kann. Ist wohl wie vieles auch ne
> Geschmacksfrage. :-)
Bei der Codeänderung sollte man nach Möglichkeit so wenig wie möglich
eingeschränkt werden. Und es gilt das DRY Prinzip. Alles nur einmal
definieren.
cu
JustTryIt
Die Redaktion sucht zum nächstmöglichen Zeitpunkt einen Redakteur (m/w) oder Volontär (m/w) in Festanstellung.
Auf 156 Seiten vermittelt das von heise Developer zusammengestellte Magazin alle wichtigen Grundlagen, um Entwickler für den Einstieg in die App-Entwicklung für iOS, Android, Windows Phone oder Cross-Plattform fit zu machen. Jetzt im Heise-Shop verfügbar.
Der Protagonist der schlicht "Programmierer" genannten Geschichte präsentiert im Rahmen einer großen CeBIT-Show seine bahnbrechenden Erfindungen in den Gebieten Künstliche Intelligenz und Robotik.