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 _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.netfielders.de http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-german