[TYPO3-german] TV BASH: was: Re: Portierung auf TemplaVoila

[Mathias Schreiber [wmdb >]]

Nikolas Hagelstein schrieb:
>> Manchmal muss man einmal produzierten Mist einfach wegschmeissen.
> Sehr richtig.
> Refactoring ist das glaub ich das Fachwort ;)

Danke :)

> Magst Du mal Deine Erfahrungen diesbezüglich teilen?
> Also zur nachbildung von FCE's fällt mir da a toc einiges ein.
> 
> Ein TV ähnliches Pagemodule speziel im Hinblick 
> auf flexible "content container" Anzahl und custom Anordnung dieser, da muss ich passen.

Das Stichwort sind Sitemaps.
Ich sage ja auch die ganze Zeit, ich hab die Anforderung noch nie gehabt 
und da ist vom Fotografen nebenan über Reportingplatform für großen 
Mobilfunkprovider bis Knowledgebase für Autos aus Schwaben echt alles 
dabei gewesen.

>> Da sind die Gesichter der Redakteure nämlich immer lang, wenn 20 Teaser
>> auf eine Seite verweisen und eine Textänderung an 20 Stellen gemacht
>> werden muss.
> Mja, aber das ist ja kein generelles TV Problem sondern beknackt zusammen
> gekloppter Content oder missversteh ich das hier?

Wie gesagt, was wir bis jetzt an TV Installationen bekommen haben, war 
irgendwie IMMER "beknackt zusammen gekloppter Content" - vielleicht bin 
ich auch einfach unlucky :)

> Hmmm .. ist IMHO mit TV machbar wobei natürlich speziell die Lokalisierung
> aufgrund der inkosistenten Datenhaltung etwas Aufmerksamkeit erfordert.

DAM und Flexforms - enjoy :)
Hintergrund:
DAM Relationstabelle schreibt folgendes:
DAM-UID, RECORD-UID, tablename, fieldname
Wie genau ist denn jetzt der Fieldname in nem Flexform?
pi_flexform?
tv_datastructure?
Und wie genau mach ich das mit der Reihenfolge?
In nem Flexform hast du nämlich ggf. 20 Bilder in einem Feld in der 
DB... und nu?
Und du kannst ganz clever hingehen und im Fieldname den "Pfad" im XML 
speichern (damit hast dann das gröbste weg).
Jetzt nimm den Record und kopier den mal :)

Worum es geht:
Inhalte gehören sauber strukturiert in die DB und nicht wild in XML 
zusammengewürfelt, da kann ichs gleich in ne Textdatei schreiben.
Jetzt wird das Argument kommen "jaaaaa, kann man ja alles über PHP und 
SimpleXML wieder zusammen nageln".
Da zitiere ich dann immer wieder gerne "Jagd auf Roter Oktober":
"Würdest du ne Interkontinentalrakete horizontal starten?"
"Klar, aber warum?"

:)

>> Ok, das verstehe ich jetzt mal als Unterstellung, daher der
>> entsprechende Konter:
>> Ich wiederhole es gerne nochmal:
>> Wir fixen TV Installationen, deren Devs fahrlässig auf eine
>> festgefahrene, unperformante, chaotische Technik aufgesetzt haben.
>> D.h. die Jobs kommen durch TV, NICHT durch "normales" Templating.
>> Es ist mir vollkommen unklar, wie das noch deutlicher auszudrücken ist.
> Jede Wette, das es auch genug "Bordmittel Installationen" gibt bei denen das notwendig ist ;>.

Klar, davon gibts auch welche.
Der Witz ist nur, dass das Verhältnis mit 4:1 zuungunsten von TV etwas 
unausgewogen ist.

>> Dann entkräfte doch mal die Nachteile von TV... auf die gehst du
>> nämlich nicht ein.
> Hmmm .. Nachteile entkräften oder Vorteile unterstreiche ist ja objektiv nicht wirklich möglich.
> Man kann beide höchstens in Bezug zu konkreten Anforderungen, Aufgabenstellungen und Gegebenheiten setzen
> und sie in diesem Licht betrachten und genau das sollte man ja auch mit Tellerandblick links und rechts vor 
> jedem neuen Projekt tun.
> 
>> bewahren, dass du irgendwann in der Scheisse steckst, weil du auf
>> einmal Anforderung hast, die mit TV einfach NICHT umzusetzen ist. 
> Nur mal so, ernsthaft interessiert, nenn mal eine.

Hab's oben mal ausgeführt.

> Mal abgesehen davon, kann sich eine Projekt Anforderung so sehr ändern das es sein, 
> das man selbst mit TYPO3 in der "Scheisse2 steckt.
> Und in dem Fall kann man dem Kunden auch deutlich erklären,
> das er n neues Auto braucht, wenn er nicht mehr Formel 1 fahren möchte sondern auf einmal Offroadrennen. ;)

Vollkommen richtig... unterschied:
Ohne TV hab ich die Daten in ner sauberen Struktur und kann problemlos 
neu bauen.

:)


-- 
TYPO3 certified interogator
T3DD09 Entertainer