[TYPO3-german] mastertemplate Bernd: DANKE! | Andreas: Mappingmanager

Mon Jul 9 00:55:01 CEST 2007

Hi Andi

Du hast mich so ein wenig auf die Palme gebracht. Solltest Du dich bei 
irgendwas da unten auf den Schlips getreten fühlen, so nimm es einfach 
nicht so ernst.
> Sich eine Virtuelle Person Teilen ist eine gute Idee!
>   
tsrepgroup wäre da eine sinnvolle Sache. Da die gesamte tsrep Seite mehr 
als nur das Librepository werden soll, wäre eine feinere Gliederung aber 
sinnvoll. Momentan sind das aber nicht gelegte Eier.
> Bei dem wec, dass Sebastian meint geht es ja um das ggf. von der wec in libs
> eingefuegte wec - uebrigens bis heute macht das die WEC NICHT ;-) 
Ne ging es mir nicht! Mir ging es darum das wir in der Namenskonvention 
nicht dem Entwickler vorschreiben sollten seine Constants/Pfade/CSS mit 
WEC vollzustopfen. Pfade und CSS sind auch nicht mit WEC in deren 
Namingconvention, deswegen spricht a auch nix dagegen diesen Teil zu 
übernehmen. Mir geht es lediglich um die Constants. Siehe weiter unten 
Beispiele.
Ich habe rein gar nichts dagegen wenn sich die WEC durch Einspielen von 
Libs und Templates beteiligt, solange sie sich an die durch die 
TSRep-Group festgelegte Namenskonvention hält. Die WEC ist ausdrücklich 
eingeladen sich an der Entwicklung einer solchen zu beteiligen.

Ich habe den Prototyp jetzt soweit das das SVN wieder funktioniert. Nach 
einem Serverupdate gabs Probleme mit SVN, weil der SVNServer als root 
laufen wollte. Aus Sicherheitsgründen ist das natürlich ein Unding. Das 
habe ich jetzt geändert, jetzt läuft er unter einem User mit den aufs 
Nötigste beschränkten Rechten.

> Das andere was Sebastian ansprach waren die Variablen in den Constants die
> die WEC dort vergibt. 
Das ist es was ich ansprach. Nicht die WEC Libraries. Solange der Nutzer 
sich zwischen der Lib der WEC und einer anderen äquivalenten entscheiden 
kann, kan die WEC gerne missionarisch tätig werden.

> Die haengen jedoch jeider vom Extensionkey ab 
Wieso hängen bitte Constants vom Extension Key ab? Es kommt drauf an mit 
welchem Namen eine Konstante aufgerufen wird, und nicht auf den Namen 
der Extension. Zumindest ist mir der Fall noch nicht unter gekommen. Es 
geht darum das der Entwickler später nicht für ein und den selben Aspekt 
5 Variablen füllen muss, da das feheranfällig wäre. Es ist doch völliger 
Humbug vom Etwickler zu erwarten das er pflegt

### Feeding the constants used in included libs
wec.rootpage = 1
tsrep.rootpage = 1
t3pack.rootpage = 1
...
...
...
elmar.startseite = 1

###do something else

DAFÜR suche ich einen Standard.
Auch weil eine Doppeltbelegung zu Fehler führen könnte (lib1 und lib2 
nutzen beide {$importantvar}, nur leider im einen Fall wird der News 
Sysfolder erwartet, im anderen Fall der Newsletter Sysfolder).

> Wir machen das im
> T3Pack allerdings ueber einen kleinen Umweg. 
Ja, und diesen Umweg kann man als Mapping Manager implementieren. Damit 
würden die Templates der WEC TSRep konform und somit benutzbar. Den 
Mapping Manager kann man natürlich erst schreiben, wenn die 
Namenskonvention vorliegt. Sollte es nicht möglich sein Konstantennamen 
innerhalb der Lib zu überschreiben, dürfte es kein Problem darstellen 
eine entsprechende Extension zu implementieren (bzw. diese 
Funktionalität in die Extension tsrep aufzunehmen).

> Sebastian hat ja unsere libs
> und divs usw. vorliegen. Das waere zB.in meinen Augen ein sehr NEUTRALER und
> zudem SEHR Flexibler und gangbarer weg. 
Räusper. Hängen noch in meinem Skype Unterhaltungsprotokoll. Ich würde 
mich freuen wenn Du die später gemäss der TSRep Namenskonvention in der 
TSRep einstellst.
[...SCHNIPP...] Sorry Andreas, ich glaube ich war jetzt der Einzige der 
Dir folgen konnte, weil Du einen Code erklärt hast der nur Dir und mir 
und Deinen Kunden vorliegt.
> Das einzige was wir bei den Templates z.B. von der WEC uebernommen haben ist
> der Name fuer die ContentElemente, da wir sonst nicht mehr deren templates
> und die nicht unsere benutzen koennten.
>
> field_maincontent
> field_rightcontent
> field_leftcontent
>
> in eingen Templates kommt hinzu
> field_subcontent
> field_bannercontent
> field_topcontent
>
>   
Gegen die habe ich nix einzuwenden. Ich bezog mich auf TS Constants wie

$constants.wec.dateFormat
$constants.wec.timeFormat

> Wie ihr seht sind das sehr CHRISTLICHE Begriffe die sicher auch auf die WEC
> hindeuten oder? 
So,jetzt passt der Satz auch ohne Ironie ;-).

> Also Spass beiseite, ihr seht dass auch die WEC die
> Templates innendrinnen bis auf deren CopyrightVermerk absolut mit weltlichen
> Begriffen versieht!
>
>   
Ich weiss. Ich würde mich wiederholen würde ich darauf antworten.
> Vorschlaege Sammeln und Abstimmen ist gut und schoen, fuer uns aendert das
> jedoch in unserem Vorgehen nichts. 
Du scheinst ja dr Community sehr verbunden ;-). Macht alle so wie wir, 
sonst machen wir nicht mit. Ich könnte das jetzt zuspitzen, unterlasse 
es aber mit Rücksicht auf Kasper.

> Abstimmungen z.B. die nur darauf aussind einen neuen Namen zu finden enden
> dann in spaltungen.
>
>   
Spalter!
> Aber Clonen ist IN. und jeder Versuch nun einen
> neuen Standard beside dem bereits vielfach (wenn auch nicht offiziell in
> Gebrauch befindlichen WEC-Standard) waere absurd. Hurra es lebe die
> Vielstaaterei!
>
>   
Es gibt einen wesentlichen Unterschied zwischen TSRep und TER. TSRep 
wird von Anfang an überwacht. Und nebenbei hindert niemand den 
"geklonten" Autor seine Lib/DIV umdie entsprechende Funktionalität zu 
erweitern.
> WEC-Integration ist daher der einzig
> wirklich gangbare WEG. 
Ja, mit *** Hilfe. Hast Du diese Art zu sprechen auf einer 
Priesterschule gelernt?
> Ein anderer - welcher auch immer haette von TYPO3
> Association eingeschlagen werden muessen schon vor 2004, denn seither sind
> Paketloesungen im Gespraech OHNE dass auch nur ansatzweise etwas durch
> TYPO3.ORG Association oder wen auch immer entstand 
Dann war ja der Bedarf offensichtlich nicht gross genug, denn seit 2004 
sind massiv neue Nutzer für TYPO3 hinzugekommen.
> - Ausser den Paketen der
> WEC! Seit froh darueber und nutzt nun da Potential - last euch eben nicht
> von der Webempoweredchurch empoweren, sondern EMPOWERED die
> webempoweredchurch Gemeinde durch nutzung des gleichen Standards.
>
>   
Ja, mit *** Hilfe.
> Entscheided ruhig gegen die WEC, aber dieser Standard wird sich langfristig
> etablieren, glaubt mir! und da bin ich mir SEHR SICHER! alles andere ist
> hier humbuk. Springt lieber auf den Fahrenden Zug bevor er abgefahren ist
> und gewinnt die WEC Kunden!
>
>   
Ja, mit *** Hilfe.

Also ich fasse mal das Fazit zusammen:
Wir sind alle einer Meinung, man kann die Standars der WEC übernehmen. 
Eine Prüfung der Sinnhaftigkeit ist trotzdem IMMER anzuraten. Wenn wir 
etwas finden was in irgendwelchen Punkten hinderlich sein sollte, wird 
die WEC sicher auch kein Proble haben entsprechende Änderungen zu machen.

Was man nicht in die Namenskonvention aufnehmen kann sind von der  WEC 
verwendete Konstanten, da sie den Namen WEC in sich tragen. Man kann 
einem Entwickler einfach nicht aufs Auge drücken, seine Konstanten mit 
WEC zu benennen. Konstantennamen müssen neutral sein. Und wie Elmar 
schon angemerkt hat, tsrep IST neutral. Oder was bitte wird Dir jemand 
sagen wenn Du ihn fragst: "wer steckt hinter tsrep.typo3.org"? 99% 
würden dann sicher auch später wenn das Projekt gross ist sagen: TYPO3
Sie würden nicht sagen TSREP und schon gar nicht Sebastian Böttger und 
ERST RECHT NICHT Cross Content Media! Also WIESO ist das NICHT NEUTRAL?

Ich ziehe hier schliesslich kein ccm_tsrep und tsrep.[cross content 
webseite].com hoch!
> Schoenen Abend
> Andi
>
>
>   
Gute Nacht,

Sebastian