Clansuite Community Forum


 
Willkommen Gast. Bitte einloggen oder registrieren.
Haben Sie Ihre Aktivierungs E-Mail übersehen?

Einloggen mit Benutzername, Passwort und Sitzungslänge
 
Seiten: [1]   Nach unten
  Drucken  
Autor Thema: Bin wieder da!  (Gelesen 369 mal)
0 Mitglieder und 1 Gast betrachten dieses Thema.
paulbr
Developer
*****
Offline Offline

Beiträge: 126


« am: April 28, 2011, 12:16:59 »

Hallo zusammen,

so hab mein aktuelles Projekt abgeschlossen und stehe wieder zur Verfügung.
Hat leider etwas länger gedauert als geplant, aber Ihr wisst ja das beim Programmieren
die Zeit nie genau kalkuliert werden kann. Naja zumindest ist es bei mir der Fall Smiley

Es hat sich ja einiges getan habe ich gesehen.

Zu der Nachricht: http://forum.clansuite.com/index.php/topic,4275.msg5564.html#msg5564 für das XDebug gibt es nun auch ein Webgrind in PHP programmiert, man braucht nicht mehr das
Windows Tool installieren. Es ist hier erhätlich: http://code.google.com/p/webgrind/

Zur Clansuite:
@jens warum hast du die SERVER_URL auf gethostname() gesetzt?
das funktioniert zumindest bei mir Lokal nicht mehr, da ich meinen Wampserver auf Windows
laufen habe. Der Host ist in diesem Fall mein PC-Name, nicht die Domain welche ich im vhost
definiert habe. Somit stimmt der Pfad nicht mehr.

Die Umstellung auf Doctrine2 hat ja einiges verändert, dass muss ich mir erstmal richtig anschauen.
Hatte mich grad an Doctrine1 gewöhnt gehabt  Smiley

Den CssBuilder hatte ich bei dem gerade abgeschlossenen Projekt eingesetzt und entsprechend
ausgebaut. Beim Start des builders kommt nun ein Formular welches default Pfade und Themen
vorgibt (im Formular änderbar). Zudem kann die Core, das Backend und das Frontend nun zusammen,
einzeln oder gemischt, z.b. core + frontend, kompiliert werden.
Auch können mittels checkbox diverse Browser zum kompilieren an- oder abgewählt werden.
Dazu gibt es eine neue Klasse: browserinfo.php, welche in die theme.core.php eingebunden
werden kann, um je nach browser die richtige import.css zu inkludieren (z.b. import.css, import_ie.css...)
Ob man das benötigt weiss ich noch nicht, aber ich habe im letzten Projekt die Seiten an 5 Browsern
exakt anpassen müssen, da war es unumgänglich für jeden Browser eigene Styles zu definieren.
Ich werde das Teil die Tage mal überarbeiten, anpassen und dann ins svn stellen.

Weitere Dinge der Clansuite welche mir aufgefallen sind:

Nur IE:
  - Der IE akzeptiert kein <script type="application/javascript"> das muss
    überall geändert werden auf <script type="text/javascript">
    Der IE führt es sonst nicht aus, weil er damit ein Object erwartet.
    Beispiel: Ein Login mit dem IE8 ist nicht möglich da der hash nicht erzeugt wird.

Generell:
  - Bei mehreren Sprachen, klappt die Umschaltung der Sprache nur für die Seite auf der man sich
    befindet. Beim Wechsel auf eine andere Seite hat man wieder die default Sprache.
    das Problem liegt hier in der localization.core.php function getLocale()
    Wenn man per language_via_url die Sprache umschaltet, wird dies nur für die aufzurufende Seite
    ermöglicht, weil danach die language_via_url ja nicht mehr in der session steht und dadurch die
    defaultsprache des Browsers geladen wird. Hier muss ein Cookie gesetzt werden.
    Auch ist hier die Überlegung ob man überhaupt auf die Browsersprache muss, bei mehrsprachigen
    Webseiten kann man die defaultsprache ja in die config speichern.
    z.B. clansuite.de -> Standardsprache "de" -> production_de.config.php
    in der staging.core.php dann wenn url = clansuite.de eben die production_de.config.php laden.
    Ich habe das im letzten Projekt mit 16 Sprachen auf dieser Art gemacht, klappt hervorragend.

Ich habe noch nicht nachgeschaut wie es in der aktuellen version ist, ob diese Fehler noch vorhanden
sind oder bereits behoben wurden. Diese Testergebnisse hatte ich noch auf meinem grossen Zettel
stehen, bin aber aus Zeitgründen noch nicht dazu gekommen diese zu erwähnen bzw. zu Integrieren.

@jens
Ich denke wir sollten dringend mal wieder ein Meeting im TS abhalten.
Es hat sich doch einiges getan in den letzten Wochen/Monaten.

gruss
Paul

Gespeichert
Jens-A. Koch
Maintainer
*
Offline Offline

Beiträge: 574

One-Man Team


« Antworten #1 am: April 29, 2011, 10:11:57 »

Hallo Paul - Willkommen zurück,

Änderungen der letzten Zeit
Ja, es hat sich einiges getan, wenn auch nur Kleinigkeiten.
Doctrine2 ist im Rennen und schlägt sich deutlich besser als der Vorgänger.
Ich habe an der Testsuite gearbeitet, einige Tests erstellt und die Coverage teilweise zum Laufen bekommen. Das Coverage-Reporting zickt noch etwas.

Webgrind:
Guter Hinweis. Wir könnten das in unser Serverpack integrieren.

Bug: warum hast du die SERVER_URL auf gethostname() gesetzt?
Wahrscheinlich hab ich irgendetwas getestet... ist jedenfalls zurückgesetzt auf $_SERVER['SERVER_NAME']
http://trac.clansuite.com/changeset/5214

Bug: application/javascript und IE
Danke. Ersetzung ist drin.
http://trac.clansuite.com/changeset/5213

CSS Builder
Das hört sich sehr gut an. Ich habe nur einige Kleinigkeiten dort verändert, insgesamt sollte ein Merge mit deinen Veränderungen daher funktionieren bzw. nur wenige Konflikte aufwerfen.

Was browserinfo.php betrifft, so lasse ich mich gern überraschen.
Um die Probleme mit get_browser() zu beheben und mehr Infos zu besorgen, hab ich "browscap" (https://github.com/garetjax/phpbrowscap) in die Libraries gelegt.

language_via_url
Das ist eigentlich nur für Gast-Nutzer relevant.
Für registrierte und eingeloggte Nutzer können wir die Language aus der User-Tabelle ziehen.
Sprachauswahl des Nutzers kann im User-Profil erfolgen.
Diese Sprachauswahl kann durch getLocale() schonmal eingegrenzt werden.

Die Struktur für das Setzen der Language ist etwas kompliziert (Toggle, Session, User-Table).
Ich muss die Language-Fallbacks dokumentieren (http://trac.clansuite.com/ticket/204).

Alle Sachen die auf dem großen Fehlerzettel stehen bitte ins Forum oder gleich in den Bugtracker (http://trac.clansuite.com/newticket). Freu mich schon Smiley

Soviel erstmal, Grüße Jens
Gespeichert

Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (Wie man Fragen richtig stellt).
paulbr
Developer
*****
Offline Offline

Beiträge: 126


« Antworten #2 am: April 29, 2011, 10:58:45 »

Hallo jens,

Zitat
- language_via_url ist eigentlich nur für Gast-Nutzer relevant.
Für registrierte und eingeloggte Nutzer können wir, das Language aus der User-Tabelle ziehen.
Sprachauswahl des Nutzers kann im User-Profil erfolgen.

naja ich denke es macht wenig Sinn, wenn ein user erstmal in seine Administration muss,
um die Sprache zu wechseln, nur weil er die Webseiten mal in einer anderen Sprache sehen will.
Ich denke da speziell an die Designer, die müssen ja Ihre defaultsprache ansonsten ständig umstellen.

Code:
    public function getLocale()
    {
        # if language_via_url was used, the filter set the URL value to the session
        if(isset($_SESSION['user']['language_via_url']) === true
            and ($_SESSION['user']['language_via_url'] == 1))
        {
            # use language setting from session
            $this->locale = $_SESSION['user']['language'];

            // write language in Cookie
            $cookie_lifetime = time() + round(60*60); // 1 hour
            $cookie_string = $this->locale;
            setcookie('cs_language', $cookie_string, $cookie_lifetime);
            unset($cookie_string, $cookie_lifetime);
        }
        else # get language from the cookie or browser or config AND set it to session
        {
            # Check for login cookie
            if ( isset($_COOKIE['cs_language']) )
            {
                $this->locale = $_COOKIE['cs_language'];
            }
            else
            {
                $this->locale = $this->getLanguage();
                $_SESSION['user']['language'] = $this->locale;

                if(empty($this->locale)) # 3) get the default language from config as fallback
                {
                    $this->locale = self::$config['language']['default'];
                }
            }
        }

        return $this->locale;
    }

Mit einem Cookie könnte man das umgehen, man kann das Cookie ja entsprechend in der Zeit
anpassen, also 30 min. oder max 1 std. oder wie auch immer.
Zumindest bleibt man so in der ausgewählten Sprache und kann die einzelnen Seiten aufrufen
ohne das Clansuite auf die defaultsprache zurückspringt.
Was hier vor dem Auslesen der browser sprache stehen sollte, wäre erstmal eine prüfung ob der user
eine default Sprache hat und diese dann zu nehmen. Danach erst die browsersprache, dann die aus
der config.

Zitat
Die Struktur für das Setzen der Language ist etwas kompliziert (Toggle, Session, User-Table).
Ich muss die Language-Fallbacks dokumentieren (http://trac.clansuite.com/ticket/204).
Somit würde der Akt entfallen!

Problematischer für die Languages ist, das jedesmal bei klick auf eine Sprache
diese als get an die URL angehängt wird. ist etwas unschön wenn da mehrmals
&lang=de&lang=en&lang=de zu sehen ist Smiley
Das könnte man evtl. in der render.base.php umgehen:

Code:
    public function getConstants()
    {
        $modulename = Clansuite_HttpRequest::getRoute()->getModuleName();
        $template_constants = array();

        # URI-Helper prepare for Languages
        $urilanguage = Clansuite_HttpRequest::getRequestURI();
        $urilanguage = WWW_ROOT . mb_substr($urilanguage, 1);
        $urilanguage = str_replace( '&amp;', '&', $urilanguage);
        if( false !== mb_strpos( $urilanguage, '?lang=' ) )
        {
            $part1 = mb_substr( $urilanguage, 0, mb_strpos( $urilanguage, '?lang=' ) );
            $part2 = mb_substr( $urilanguage, mb_strpos( $urilanguage, '?lang=' )+9  );
            $urilanguage = $part1.'?'.$part2;
        }
        if( false !== mb_strpos( $urilanguage, '&lang=' ) ) {
            $urilanguage = mb_substr( $urilanguage, 0, mb_strpos( $urilanguage, '&lang=' ) );
        }

        $template_constants['urilanguage']             = $urilanguage;

        ...
In den Sprachlinks z.B. Flaggen dann ...<a href="{$urilanguage}&lang=es">... angeben
so wird immer nur 1 language parameter angehängt.
Ist aber nicht so wichtig, ist mir nur mal so am Rande unschön aufgefallen, weswegen ich da
ein bischen experimentiert habe Smiley

Für den CssBuilder dachte ich an 2 Versionen:
 - mit Form um diverse Einstellungen machen zu können
 - eine CLi version mit parametern im silent mode

Auf jedenfall denke ich das es an der Zeit ist den Builder als Clansuite Class zu integrieren.

Habe im letzten Projekt für den Shop ein PayPal Modul integriert.
Denke mir das das auch für die Clankasse interessant wäre, wenn diese mal irgendwann erstellt wird.

Zitat
Was browserinfo.php betrifft, so lasse ich mich gern überraschen.

Das ist nichts grossartiges, simple und einfach gestrickt, aber ausbaufähig.
Was mir an der browscap nicht gefällt, ist das man diese ständig auf den neuesten Stand
halten muss. d.H. sie muss am Server ja auch immer wieder mal erneuert werden.

Die definitionen in der browserinfo.php könnte man irgendwann in der Administration Änderbar
bzw. erweiterbar gestalten. Es muss ja hier nicht jeder auf dem Markt befindliche browser
abgedeckt werden, zudem macht es meiner meinung auch keinen Sinn mehr Uralte Browser
mit zu schleifen.


Das sind nur Lösungsansätze die ich auf die schnelle mal ausprobiert habe, allerdings an der alten
Clansuite Struktur, welche ich noch hatte. Die aktuelle muss ich mir erstmal genau ansehen,
da hat sich ja einiges geändert.
Wie gesagt, ich denke wir sollten mal ein Meeting abhalten!

gruss
paul
Gespeichert
Jens-A. Koch
Maintainer
*
Offline Offline

Beiträge: 574

One-Man Team


« Antworten #3 am: April 29, 2011, 04:30:31 »

Zitat
naja ich denke es macht wenig Sinn, wenn ein user erstmal in seine Administration muss,
um die Sprache zu wechseln, nur weil er die Webseiten mal in einer anderen Sprache sehen will.
Ich denke da speziell an die Designer, die müssen ja Ihre defaultsprache ansonsten ständig umstellen.
Nein, Sprachwechsel in der User-Verwaltung ist der Standardfall.
Vergleiche, statt vieler Systeme: Joomla, Xoops, SimpleMachinesForum.

Einen ständigen Wechsel zu Übersetzungzwecken oder Designzwecken gibt es nicht.
Die Designer designen hoffentlich und ausschließlich unter Verwendung englischsprachiger Lokalisierungsplatzhalter. Nach erfolgreicher Übersetzung kann man dann noch ein paar Änderungen an der Wortwahl treffen, um etwaige Designverschiebungen auszugleichen.
Um die "Verschiebungen" festzustellen müssen sie nicht umstellen, sondern arbeiten von Anfang an in ihrer Sprache. So sieht der spanischsprachige Übersetzer und Designer die noch nicht übersetzten Anteile in English.

Zitat
Habe im letzten Projekt für den Shop ein PayPal Modul integriert.
Denke mir das das auch für die Clankasse interessant wäre, wenn diese mal irgendwann erstellt wird.
Hört sich gut an. Wir können es gern einbauen. Interessant ist es bestimmt für große Sportteams, um die Mitgliederbeiträge einfach einzuziehen oder auch für Shop oder bezahlbare Bereiche/Inhalte.
Wir können uns ja ein wenig in diese Richtung begeben.

PayPal halte ich für die Zahlungsabwicklung bei Clans für ungeeignet, da die relativ kleinen Mitgliederbeiträge durch die PayPal-Transaktionsgebühr nur noch kleiner werden. Nur meine persönliche Meinung. Einbauen können wir es trotzdem.

Insgesamt: 
Wir können verschiedene Zahlungsabwicklungs-APIs, einen Shop bzw. eine Clankasse einplanen.
Allerdings übersteigt das meinen derzeitigen Planungshorizont und meine Handlungsmöglichkeiten und muss daher sehr weit nach hinten auf die Roadmap.

Zitat
Das sind nur Lösungsansätze die ich auf die schnelle mal ausprobiert habe, allerdings an der alten Clansuite Struktur, welche ich noch hatte. Die aktuelle muss ich mir erstmal genau ansehen,
da hat sich ja einiges geändert. Wie gesagt, ich denke wir sollten mal ein Meeting abhalten!
Genau genommen hat sich an der Struktur nur wenig geändert. Die Doctrine Core Klasse ist völlig ausgetauscht. Bedingt durch D2 hat sich auch die Query-Konstruktion verändert.

Ich hab wesentlicher mehr Zeit in den (oft unsichtbaren) Projektrahmen investiert, als in direkte Programmierung an Clansuite. Serverwartung (Debian 6 Upgrade), Serververwaltung geändert, Umstellung Hudson auf Jenkins als ContinousIntegration-Server, Verfeinerung der Jenkinskonfiguration mit verschiedenen Reporting-Werkzeugen, Dokumentationserstellung in verschiedenen Formaten, IrcLogBot, Testsuite usw.).

Wir können ein TS-Meeting ansetzen, wenn etwas mehr Luft ist.
Ich möchte daher vorschlagen, besonders auch aus zeitlichen Gründen meinerseits, es erstmal beim Schreiben im Forum oder Bugtracker zubelassen. Auch gibt es derzeit keine weiteren aktiven Projektteilnehmer außer uns, die wir einbinden könnten oder müssten.

Gruß Jens
Gespeichert

Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (Wie man Fragen richtig stellt).
paulbr
Developer
*****
Offline Offline

Beiträge: 126


« Antworten #4 am: April 29, 2011, 07:40:31 »

ok

Ich werde mich mal in das d2 einarbeiten und entsprechend auch das in arbeit befindliche Forum danach anpassen.
Den CssBuilder baue ich mal als klasse um, macht ja kein Sinn den Compiler mit in modules zu integrieren.
Der neue Builder generiert für jeden browser eine eigene import.css sowohl für backend als auch für das frontend und den core. In Verbindung mit dem browsermodul wird je nach browser die korrekte
import.css geladen. So entfällt auch das lästige <!--[if IE]><![endif]--> patchen in der index.tpl

Auch müssen ja noch /modules nach und nach auf d2 angepasst werden.

Dann packen wir es mal wieder an.

gruss
paul
Gespeichert
Seiten: [1]   Nach oben
  Drucken  
 
Gehe zu:  


Powered by SMF 1.1.16 | SMF © 2006-2009, Simple Machines

Google visited last this page Mai 04, 2012, 07:11:10