Brauche helfe für eine XML Schnittstelle.

Hast Du Dir schon mal das Modul Feeds angesehen? Damit sollte sich so etwas bauen lassen.

Beste Grüße
Werner

Hallo,

ich habe für einen Kunden eine Schnittstelle für OpenImmo-Dateien (u.a.) mit Hilfe des Feeds-Modules aufgebaut – das dürfte also exakt das sein, was Du machen möchtest? Wie kann oder soll die Hilfe aussehen?

Viele Grüße,

Tobias

Ja, nach Deinen angehangenen Infos ist es das OpenImmo, da habe ich vor gut einem halben Jahr auch etwas geschrieben zum Export. Da kommt man mit dem Feedsmodul leider nicht sehr weit, wenn man flexibel sein will.

Sind auch Import Möglichkeiten vorhanden, Feeds soll anscheind dafür nicht optimal sein.

am besten erstellst du dir ein mini modul und schreibst da eine php funktion rein (je nach skills vielleicht auch klasse), machst diese über hook_menu(); mit einem url vertraut oder hängst das direkt an hook_cron();.

in deiner php funktion lädst du den stream mit simplexml_load_file(); (= http://php.net/manual/de/function.simplexml-load-file.php). anschließend speicherst du deine daten über entities (drupal 7 - http://www.istos.it/blog/drupal-entities/drupal-entities-part-3-programm...) oder über node_save(); (drupal 6 - 7; lahmer als entites-schnittstelle).

sollte im groben so funktionieren.

... ich hatte mit Feeds keine Probleme: finde es recht komfortabel, wenn man es erstmal verstanden hat.
Zumindest kann man – wenn der Standard reicht – ganz ohne Programmierkenntnisse recht schnell unterschiedliche (CSV, XML, RSS, ...) Schnittstellen aufbauen.
Nichts gegen eine Eigenprogrammierung: aber warum das Rad nochmals neu erfinden ...

und wie aufwändig ist die erstellung so einer Schnittstelle?

Edit: mit dem OpenImmo hattest du schon oben erwähnt.

git://git.drupal.org/sandbox/maen/2469709.git

Falls hier einer drauf kommt. Testet das mal bitte. Eigentlich müsst Ihr nur Immoclient anklicken, wenn Ihr dann noch ein vernünftiges views baut, habt Ihr Ruckzuck eine Immoseite gebaut mit allen Feldern eines Objekte für Openimmo.

BG

Marc

Hast du mal auf das Datum des Threads geschaut :-)

Gruß
Berthold

git ist falsch. kommt immer eine fehlermeldung head fhelt oder ähnlich

@caw: schau doch einfach mal auf der Seite der Sandbox, wie genau der Befehl zum Checkout lautet: https://www.drupal.org/project/2469709/git-instructions

git clone --branch 7.x-1.x http://git.drupal.org/sandbox/maen/2469709.git immoclient

Das Modul ermöglicht es, mit einem install die Datenstruktur von openimmo für Immobilien aufzubauen.

Das Problem:

Die Schemadatei (XSD) von openimmo besteht aus ca. 3600 Zeilen. Der Standard gibt vor wie der Datentransfer zwischen Instanzen (HP-> Portal, Desktop Client -> HP) auszusehen hat.

Dabei besteht das Problem, daß Immobilienmakler häufig einfache Lösungen wollen:
"Wohnung auf Zeit? Benutze ich nicht!" "Ich verkaufe nur Häuser und Wohnungen!"

Nichtsdestotrotz müssen die Felder für die anderen 2% ja da sein. Um eine Formulareingabe möglichst einfach zu gestalten sind die oft benutzten Felder oben angesetzt.

Heißt:
Durch vertikale und horizontale Tabs habe ich versucht das Formular möglichst intuitiv für Immomakler zu bauen. Nach ein wenig Übung können sie (getestet bei 3 Maklern), innerhalb von 10 Minuten ein Objekt komplett füllen. Dabei können Inhalte ganzer Tabs vernachlässigt werden, da die default Werte den meisten Fällen entsprechen.

Die Mehrsprachigkeit.
Der Trend der HP Anbieter für Immobilien geht in Richtung mehrerer Sprachen. Was also tun? Ich habe mich für Entity Translation entschieden, weil es dem Makler, so er denn mehrsprachig ist, kaum zuzumuten ist alle Felder mehrfach auszufüllen. Somit schrumpft für die Übersetzung der Aufwand von über 200 Felder auf ca. 10. Dies sind alles strings. Viele Felder habe ich als Checkbox, select oder radio angelegt. Die werden via assoziativ array als string gespeichert, wie seitens XSD vorgegeben, sind aber eindeutig,

Die Darstellung als Pferdefuß:
Eine vernünftige Darstellung mit der Masse an Feldern hinzubekommen ist als node so gut wie unmöglich. Daher habe ich viel Zeit geopfert um die integrierten entitites (mittels inline entity form) mit der entsprechenden Property zu versehen.
Somit kann der Drupaler mittels views seine eigene Darstellung aufbauen. Ich empfehle hierzu 2 tpl.php Files zu bauen. Eine für die Listenansicht, eine für die Einzeldarstellung der Objekte.

Warum überhaupt die entities?
Klare Antwort: flat tables in der DB zum einen und Multiinstanzen zum anderen.
Oder weniger kryptisch:
Manche Einheiten (Parken, Beschreibung des Ausbaus der Etagen, Distanzen zu wichtigen Plätzen, Distanzen zu Sporteinrichtungen...) können mehrfach vorkommen. Hierfür stehen auf Seiten drupals 2 Möglichkeiten, die ich getestet habe, zur Verfügung. Zum einen field collection, zum anderen inline_entity_form.

Das Zweite ist extrem sauber programmiert, so dass ich die hooks nutzen und die public functions der Klassen überschreiben konnte. Daher habe ich mich für inline_entity_form entschieden.

Nodes produzieren einen gewaltigen head, der nicht nötig war. Zudem hätte bedeutet alle DB Felder als field api zu bauen das noch ca. 150 Tabellen plus Revisions Tabellen mehr im System gelagert hätten. Die betrachte ich als unnötig, da der content type selbst, also immoclient, als node zur Verfügung steht. Alle entities haben ihre eigene Permission. Da "Inhalt hinzufügen" etwas unübersichtlich ist, würde ich für den Makler nur die Entity Customer aktivieren. So besteht eine 1:1 Verbindung zwischen Verkäufer und Objekt. Und Ihr könnt ein Mini CRM bauen. Diese Felder sind alle fieldsable, also freie Wahl für die Implementierenden.

genau das habe ich gemacht. so wie immer... ;)
Fehlermeldung:
fatal: Couldn't find remote ref HEAD
Unexpected end of command stream
Ich habe es einfach mal per Hand runtergeladen

na ja, bei meinen Rechnern funktioniert es, das git. Ich kann da auch nichts einstellen meines Wissens nach.

https://www.drupal.org/project/immoclient

Wow, das nenne ich mal Arbeit... seit Ewigkeiten bin ich da auf Lösungssuche und du stellst es als Modul bereit.

Freue mich riesig das jetzt testen zu können, großen Respekt vor der Leistung und deinem Zeiteinsatz und besten Dank.

Grüße Jenna

das ist aber kein XML feed oder so. Das ist nur die Grundlage: alle Felder, die von openimmo 1.2.7 gefordert werden!

Ich habe heute bei openestate darum gebeten, mir das format zu benennen, so dass ich die API schreiben kann um vom immotool nach dem Client zu mappen.

Wenn Du magst teste ausgiebig und fülle mir den issue queue! Man kann da noch einiges optimieren. Bis dato funktioniert das Ding nur für englisch und deutsch.

Falls Du sprachbegabt bist wäre französisch und italienisch nicht schlecht!

Hauptsache ein Ansatz ist da, ich mache nächste Woche ein paar Tage Urlaub und danach teste ich alles und gebe dir natürlich Rückmeldung.

Kann dir auf jeden Fall eine saubere spanische Übersetzung anbieten wenn das hilft, ich brauche hier immer de, es, en für meine Immoleute.

Grüße Jenna

Hi Maen,

ich finde das Modul ebenfalls sehr spannend!

Du schriebst:

Hast du mittlerweile eine Antwort erhalten und bist mit der Entwicklung weitergekommen?

Es scheint ja momentan keine andere Lösung zu geben, um Immobilienobjekte von einer gemeinsamen Plattform zu Immoscout / Immowelt und zu einer Drupalwebsite zu exportieren.

Bin gespannt wie es weitergeht mit dem Modul!!!

Beste Grüße,
t2k