imxTools1 und imxTools2 in einem Portal… erste Schritte sind gegangen

Bastian Schwarz Datum: 25. November 2011
Autor: Bastian Schwarz


Im Zuge des Schneebayern-Projektes besteht die Anforderung, dass die imxTools1 (für allgemeine imxTools-Inhalte) sowie die imxTools2 (für den Schneehöhenticker) parallel zueinander laufen müssen.

Dazu wurde ein neuer Task in der build.xml angelegt, der eigtl genau das gleiche tut wie der register_integration_imxtools, nur dass er das Ziel in einen imxtools2 Ordner anlegt.

Auszug aus der build.properties:

register_integration_imxtools2=2_2_0
register_integration_imxtools=1_3_0

Problem war jetzt allerdings, dass schon wie im vorigen Blogeintrag genannt, die Konfigurationsklassen gleich hießen und diese auch noch in der IMXCMS_Configuration also im CMSCore abgelegt werden konnten. Daraus ist resultiert, dass ich die Config-Klasse in der imxTools2-Integrationskomponente umbenannt habe und (ganz wichtig) einen neuen Tag für den 4_3_0_21 für den Core released habe, wo die Methoden für die imxTools Konfiguration rausgeflogen sind.

Warum habe ich das gemacht? Ganz einfach, es wird nicht zwingend benötigt und es führt nur zu weitere Verwirrung und Unflexibiltät.

Das bedeutet allerdings, dass zukünftige Projekte die auf den Core-Tag 4_3_0_21 basieren nicht mehr die Konfiguration im Core ablegen dürfen (das tun die meisten aktuell, also wird es erstmal zu Fehlern kommen), das ist aber gar kein Problem, da in imxTools1 die Klasse IMXTools_Configuration das auch selbst kann (ist eh alles statisch..) und in imxTools2 kann das über den Service erreicht werden.

Das bedeutet jetzt, imxTools1 und imxTools2 können jetzt prinzipiell in einem Portal laufen. Was dort allerdings noch nicht berücksichtigt ist (da es aktuell noch nicht benötigt wird) sind die eigentlich wirklichen Anpassungen wie z.B. die Linkgenerierung, das Caching etc. anzupassen (aktuell werden ja immer die gleichen Identifier verwendet). Das wird dann nochmal ein größeres Arbeitspaket werden.

Kommentare

Selber kommentieren:






Weitere Beiträge zum Thema Technologie


fluidvids

Autor: Benjamin Hofmann


Technologie // User Experience & Design


Gestern kam nichts, dafür heute wieder: fluidvids. Eine sehr kleine Library, um Video-Integrationen ohne viel Aufwand responsiv zu gestalten. Warum ein Skript? Nun wird sich der ein oder andere wahrscheinlich fragen, warum folgendes Konstrukt nicht ausreicht: Ganz einfach deswegen, weil damit ein Seitenverhältnis von 16:9 vorgegeben ist und man ohne zusätzliche Klassen und eine irgendwie …


Beitrag lesen
28.
Sep.
2016

Flickr und das Image Plugin oder „Dees is sowieso blääd“

Autor: Bastian Schwarz


Technologie


Gerade habe ich ein Problem für unser Kundenprojekt „Holsteinische Schweiz“ analysiert: Im Keyvisual wurden bis zu 20 Flickr-Bilder geladen. Die URLs der Bilder wurden über die Flickr API geholt und dann durch das Image Plugin geladen, entsprechend gerechnet und abgelegt. So weit, so gut. Nun das Problem: Für den Dateinamenhash benutzt ajaxImage u.a. die Breite …


Beitrag lesen
21.
Sep.
2011

There are only two hard things in Computer Science

Autor: Christian Göbel


Technologie


Rückblickend auf unseren gestrigen Workshop ein passendes Zitat: „There are only two hard things in Computer Science: cache invalidation and naming things.“ (Phil Karlton) Nachzulesen z.B. bei Martin Fowler.


Beitrag lesen
30.
April
2013

Netbeans und GIT

Autor: Florian Müller


Technologie


Ich habe mich mal während der Arbeit mit Git mit den Git Hooks beschäftigt. Ziel war es, unnötige Builds in der Pipeline zu vermeiden, welche aufgrund von Lintern fehlschlagen. Dazu wollte ich einen Pre-Commit Hook einsetzen. Ein simpler Hook, welcher vor einem Commit ausgeführt werden sollte: Wenn man über die Command line commiten will, wird diese auch …


Beitrag lesen
21.
April
2017