[TYPO3-german] Idee f|r eine neue TV-Extension! Wer macht mit?

[Sven]

Hi Mathias,

danke für Deine Kommentare!
Jetzt wird ich mal Deine Kommentare kommentieren ;-)

> Klingt alles erstmal sinnvoll.

Gell! ;-)

> > - Die Datensdtze w|rden direkt auf einer Seite bearbeitete 
> werden und 
> > nicht mehr im nervigen Listen-Modus wie bisher.
> 
> locker 80% der Listing Extensions profitieren von einfacher 
> importierbarkeit von ERP Systemen in eine mySQL Tabelle.
> Wie gehst du damit um?

Da gebe ich Dir Recht. Ein Import in FCE-Datenstrukturen ist sicher
komplizierter.

> > - Die einzelnen Daten werden auch gecached (anders als bei 
> den meisten
> > Extensions)
> 
> Auch die dynamische sortiererei?

Die Liste wohl eher nicht; aber die einzelnen Daten in der "Single-View",
was im Vergleich zu fast allen Extensions auch bereits ein wesentlicher
Fortschritt wäre, da diese die Single-View immer auf der selben Seite
anzeigen und somit nicht gecached werden kann.

> > - Genial einfache URLs (ohne Hash und Parameter), da f|r jeden 
> > Datensatz nur eine einfache Seite angelegt werden muss.
> 
> Ich freu mich auf den Seitenbaum bei 40.000 produkten gepaart 
> mit 1000 mitarbeitern :)

Das scheint mir doch sehr übertrieben! ;-)
Aber 40.000 Produkte im List-Modus zu administrieren dürfte auch nicht
gerade lustig sein! ;-D
Ich würde sogar behaupten, dass das Einsortieren in diversen Sys-Ordnern
vermutlich übersichtlicher wäre, als 200 Seiten im List-Modus (bei 20
Produkten pro Seite), oder meinst Du nicht auch?


> > - Bessere Suchmaschinen Indizierung durch bessere URLs
> 
> ack, wenn cHashes Google so beinflussen...

Nun ja, ein solcher Link: 
"index.php?id=418?&cHash=df429e128e&tx_ttnews[backPid]=419&tx_ttnews[tt_news
]=9"
dürfte zumindest nicht gerade förderlich sein.
 
> > - Kein Problem mit Mehrsprachigkeit, da in FCE ja bereits eingebaut.
> 
> Daf|r erstickst du in redundanten Daten.
> Merke:
> Der Mitarbeiter Mathias Schreiber hei_t auf spanisch dhnlich...

Klar, kommt das natürlich auf die Daten an. Aber Du mußt sie ja nicht
übersetzen, wenn Du nicht willst.
Und abgesehen davon, sehe ich da auch keine prinzipiellen Vorteil bei den
bisherigen Extensions in Bezug auf Übersetzungen.

> Wie gedenkst du die Performance bei gro_en Datenmengen 
> aufrecht zu erhalten?
> Nehmen wir wirklich mal die 40.000 Produkte an.
> Jetzt will ich die ersten 100 nach Warengruppe angezeigt bekommen.
> Also liest du ALLE Records aus der DB aus, zerlegst die in 
> PHP aus XML in ein Array und fdngst dann an, die sortiert auszugeben.

Es stimmt natürlich, dass die Performance maßgäblich an den XML-Fähigkeiten
von PHP hängt.
Aber ich denke, dass Dein Beispiel mit 40.000 Produkten sicher auch sehr
hoch gegriffen ist.
In der Praxis dürften es wohl meist deutlich weniger Datensätze sein und
sollte man doch mal eine solche riesen Datensatz-Sammlung haben, muss man
halt ein paar Euros mehr für einen leistungsfähigen Server investieren ;-)

Aber ich stimme Dir zu, dass man in einem sehr frühen Stadium einig
Performancetests machen sollte.

> Hoffe, jetzt nicht zu bvswillig r|berzukommen.
> Ich mvchte nur auf einige Stolpersteine hinweisen, damit du 
> die nicht aus den augen verlierst.

Schon ok, so lange es konstruktive Kritik ist! :-)

 
> > Da leider auch meine Zeit recht beschrdnkt ist, wdre ich besonders 
> > dankbar, wenn sich gleich Freiwillige melden w|rden, die daran 
> > mitarbeiten wollen. (Als erstes brduchte ich gleich mal einen guten 
> > \bersetzer f|r's Englische, da mein "aktives" Englisch nicht 
> > sonderlich perfekt ist.)
> 
> Englisch mach ich gerne f|r dich.
> Programmiertechnisch hab ich wenig bis garkeine Zeit.

Prima! :-D
Wäre es arg unverschämt, wenn ich Dich gleich bitten würde, meine
Beschreibung dieser Idee ins Englische zu übersetzen? X-)
Ich würde sie nämlich gerne in der englischen TV-Mailingliste und im Wiki
vorstellen.
Wäre echt super von Dir!!!

Viele Grüße...Sven