Am 26.03.2013 20:37, schrieb Peter Linzenkirchner:
Wenn gar nichts erscheint, fehlt wahrscheinlich der letzte Teil
(plugin.tx_wecmap_pi3.tables.10).

Das habe ich mittlerweile gefunden :-)

Das steht aber auch so in der Doku (als tables.*.description) in
der TS-Referenz zum pi3-Plugin.

na ja ... im Manual finde ich nichts, ...
Das steht so in der Tabelle drin. Jedenfalls ist ein plugin.tx_wecmap_pi3.marker aus gutem Grund nicht erwähnt. ;-)

Vielleicht nehme ich noch ein Beispiel auf, wie Du vorgeschlagen hast. Wenn Du Zeit und Lust hast, nehme ich auch gerne fertige Textvorschläge für die Doku entgegen.

Die Generierung Klassenangabe ist versehentlich im Code
(res/wecmap.js)

Du meinst das hier: ...
Ja, genau.

Wenn du dabei bist, mach noch eine andere Änderung:
class.tx_wecmap_marker_google.php, Zeile 138: $markerContent[0] .=
'<br /><div id="'.$this->mapName.'_di .... => nimm das <br /> raus.
Da alles in div-Containern ist, brauchts keine Zeilenschaltung. Und
das br per CSS rauszumachen schmerzt  ...
Das hatte ich aus Kompatibilitätsgründen zu V2.x drin gelassen.

Wenn wir schon dabei sind, ein paar Feature-Requests, die
nice-to-have wären:
Mach bitte einzelne Requests auf Forge auf. Das ist einfacher nachzuhalten.

$jsFile  = t3lib_extMgm::siteRelPath('wec_map') . 'res/wecmap.js';
$jsFile2 = t3lib_extMgm::siteRelPath('wec_map') .
'res/copyrights.js';

=> konfigurierbar per Typoscript wäre schön. Dann kann man den Output
bequem selbst anpassen, ohne dass die Änderungen nach einem Update
weg sind.
Spricht nichts dagegen.

Request 2:

=> alle <div> und <span> mit Klassen versehen. Klassenlose Tags sind
schwer stylebar.
Scheint mir kompatibel zu existieren Installationen sein.

Request 3:

=> alle Klassen mit einem Namensraum versehen. .marker ist nicht so
schön: das kann zu Konflikten führen. Klassen wie wecmap_marker sind
besser.
Da kommt der alte Klassenname auch wieder aus der V2.x. Mit .tx-wecmap-map .marker sollte man auch dieses div treffen.

Für die Breite gibt es im Moment eine Vorgabe "{ maxWidth: 300 }".
Ohne eine solche maximale Breite habe ich es nicht stabil ans
Laufen gebracht. Vermutlich lässt sich dann trotz der Klassennamen
die Breite nur begrenzt anpassen. Vielleicht hat ja jemand noch
eine Idee dazu, wie das am besten zu lösen ist.

Mein Problem war (ist) vor allem, dass ich Scrollbalken bekomme.
... Offenbar wird die Höhe falsch berechnet, dadurch
erscheinen senkrechte Scrollbalken, und die wiederum führen zu
waagrechten, wegen der Breite des senkrechten Scrollbalkens :-( Das
muss an infobubble.js liegen.
Ich habe dazu keine Lösung. Trag's auf Forge ein. Vielleicht findet sich ja noch jemand mit einer Idee. Evtl. muss man auch infobubble.js gegen eine andere Lib austauschen. Bei uns ist es sehr unterschiedlich, ob man Scrollbalken bekommt.

Ansonsten funktioniert das Teil wie eine Eins :-)
Schön zu hören, wobei ein Großteil der Lorbeeren nach wie vor an das WEC-Team geht, das die tolle Basis geschaffen hat. Von mir kommt ja "nur" die Anpassung an die neue Google-API.

Gruß,

Jan
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Antwort per Email an