[TYPO3-german] kommunikation zwischen content objekten einer eigenen extension

[Martin Ficzel]

> Eine Gegenfrage, um mein Verständnis ein wenig voran zu treiben. Warum
> kombinierst du die Anzeige der Liste und die Suche nicht in einem
> PLugin. So hast du jederzeit Zugriff auf den Suchbegriff und kannst die
> Formatierung der Liste vor der Darstellung der Suche angehen.
> 
> Falls dies aufgrund der Komplexität nicht möglich ist, hier Kommentare
> zu deinen andere Ansätzen:

genau dazu tendiere ich auch (siehe 3)  ... ich war nur unsicher und 
wollte mal alle möglichen ansätze gengenüberstellen und ne meinung von 
aussen haben. ich kenne mich im core nicht soooo genau aus das ich 
wirklich sagen kann das es nicht noch ne 5. lösung viel bessere Lösung 
gibt ... daher die frage

>> Lösungsansätze und Probleme damit:
>>
>> 1. die suchfunktion in eine php funktion auslagern welche vor dem rendern der content elemente abläuft. allerdings wird es dann schwierig die suche
> durch die einstellungen im suchplugin genauer zu customizen.
> 
> Was heisst jetzt hier auslagern? Eine einzelne Funktion für die Suche in
> dem zweiten Plugin ist definitv sinnvoll. Was meinst du mit
> Schwierigkeiten bei den Einstellungen?

eine funktion wird vor dem parsen der seite aufgrufen (hook) die die 
urlVariabeln ausliest und die suche ausführt sowie das ergebnis in einer 
variablen sichert ... dumm ist das dabei einschränkungen der suche wie 
die pid welche im content element gemacht wurden nicht bekannt sind.

aber ich finde den anatz auch nicht elagant

>> 2. im listview plugin eine seperate suche laufen lassen, nachteilig sind dabei redundanter code und sinnlose performanceverschwendung. 
> 
> Korrekt selber beantwortet ;) Hiervon rate ich ab.
> 
>> 3. alle funktionen in ein plugin packen welches wie tt_news diverse modes hat wobei jeweils mehrere nacheinander eingefügt werden können. die suche erfolgt dann im allmemeinen teil der extension bevor die speziellen module gestartet werden. allerdings wird der code des plugins dabei recht stark aufgebläht desweiteren ist der redakteur dann nicht frei eigene content objekte zwischen liste und suche einzufügen. der vorteil ist das die einschränkungen der suche problemlos aus demselben cObject übernommen werden. 
> 
> Ah, hier steckt ja der von mir vorgeschlagene Ansatz. Ist denke ich
> grundsätzlich die beste Methode. Durch die Implementierung von
> unterschiedlichen Sichten auf das Plugin kannst du so z.B. das Suchfeld
> auf einer anderen Seite darstellen und dann die listview auf einer
> anderen. Du kannst so auch zwei Versionen des Plugins auf einer Seite
> betreiben. Somit wird auch das freie Platzieren von Content Elementen
> unterstützt.

genau ist auch mein favorit ... allerdings können user dann immer noch 
die performance killen indem sie nacheinander cObjects mit nur einem 
Darstellungsmode einbinden. aber das ist dann eben so

>> 4. ein unsichtbares content element welches die eigentlich suche durchführt aber keinen frontend output erzeugt wird vor den anderen beiden plugins eingefügt. Das suchplugin ist dann ein reines eingabeformular. allerdings muss ich dann 1. die ergebnisse irgendwo zwischenspeichern und 2. müssen die redakteuere sich dann an eine feste anordnung der cObjekte halten... schwierig. 
> 
> ... ähm .... nicht böse gemeint, aber da fällt mir gerade nichts zu ein
> ausser ganz schnell wieder vergessen ;)

:-)) ja ich weiss auf redakteure sollte mann sich nicht verlassen ... 
das war auch eher der vollständigkeit halber dabei

> Also, ich denke mit Methode 3 fährst du am besten.
> 
> Kannst du in deinem Newsreader bzw. E-Mail-Programm mal die
> Zeichenanzahl auf max 80 Zeichen pro Zeile stellen?

hmm eigantlich steht das auf 72 ... wo kann man das im thunderbird noch 
einstellen

danke für deine antwort ... hat mich sehr in meiner lösung bestärkt

gruß Martin