Kategorien
Frameworks GIT Kohana PHP Versionierung

xgchunker – kohana 3 modul konvertiert grosse csv/xml dateien in StdClass objekte

webpiraten opensource auf github hat ein neues repo für den xgchunker als kohana 3 modul.

er konvertiert riesige csv/xml dateien in kleine chunks als StdClass objekt, um sie dann weiter zu verarbeiten.

github.com/webpiraten/xgchunker

Kategorien
Agavi Debugging Frameworks Linux PHP Shell XML

Agavi Custom Logger implementieren

Um in Agavi custom logfiles zu erstellen, benötigt man einen eigens erstellten logger + appender in der app/config/logger.xml.

<!-- logs only custom messages in a custom log -->
<logger name="custom" class="AgaviLogger" level="'custom'">
    <appenders>
        <appender>CustomLogAppender</appender>
    </appenders>
</logger>

<appender name="CustomLogAppender" class="AgaviFileLoggerAppender" layout="DateTimeLayout">
    <ae:parameters>
        <ae:parameter name="file">%core.app_dir%/log/custom.log</ae:parameter>
    </ae:parameters>
</appender>

Dann kann man den Logger quasi überall wo der LoggerManager verfügbar ist benutzen.

$message = 'Custom logging message';
$this->getContext()->getLoggerManager()->log(new AgaviLoggerMessage($message, 'custom'), 'custom');

Und in der bash das logfile einsehen.

tail -f app/log/custom.log
Kategorien
Agavi Frameworks PHP XML

Eigene Configs in Agavi nutzen

Für diverse Aufgaben in größeren Projekten ist es notwendig, eigene XML-Konfigurationsdateien zu nutzen. Die Definition umfangreicher Einstellungen in der settings.xml wird schnell anstrengend und das Holen der Werte per AgaviConfig::get('setting.name', 'default'); unübersichtlich. Agavi bietet es aber an, eigene Konfigurationsdateien zu erstellen und diese nicht nur zu validieren, sondern auch zur Wiederverwendung zu cachen.
In der Agavi FAQ habe ich dazu mal ein Beispiel verfasst.

Einfach einen Config-Handler in der config_handlers.xml definieren:

<handler pattern="%core.config_dir%/project/foo/*.xml" class="AgaviReturnArrayConfigHandler" />

und dann direkt in den Actions, Views und Models benutzen:

if (!isset($config['baz']))
{
    throw new LogicException('baz is missing!');
}

if (isset($config['bars']))
{
    foreach ($config['bars'] as $foo => $data)
    {
        $this->doSomethingWithEach($foo, $data);
    }
}

Die XML-Datei für den obigen Code könnte beispielweise so aussehen:

<ae:configurations>
    <ae:configuration>
        <baz>asdf</baz>
        <foo>-1</foo>
        <bars>
            <some>...more data and xml...</some>
            <more>...more data and xml...</more>
            <deep>...more data and xml...</deep>
            <structs>...more data and xml...</structs>
        </bars>
    </ae:configuration>
    <ae:configuration environment="production.*">
        <baz>bleh</baz>
        <foo>1</foo>
    </ae:configuration>
</ae:configurations>

Gut zu erkennen ist der Vorteil eigener Configs: Man kann die Agavi-Features für Konfigurationsdateien nutzen und auf einfache Art und Weise environmentspezifische Einstellungen vornehmen (z.B. in „Production“ andere Werte für Logdateien, URLs oder Einstellungen nutzen als während der Entwicklung oder beim Testen).

Ebenfalls gut zu erkennen im PHP-Code ist, dass man lauter Abfragen über die Existenz bestimmer Elemente macht, die man sich mit vernünftiger Validierung sparen kann, da invalide XML-Dokumente gar nicht erst als korrekt angesehen werden von Agavi. Um seine XML-Strukturen zu validieren definiert man per validation Parameter ein XML-Schema und definiert noch gleich einen eigenen ConfigHandler, den man schreibt und per autoload.xml bekannt macht:

<handler pattern="%core.config_dir%/project/foo/*.foo.xml" class="FooDefinitionConfigHandler">
    <validation>%core.config_dir%/xsd/foo_definition.xsd</validation/>
</handler>

Der ConfigHandler könnte so beginnen:

class FooDefinitionConfigHandler extends AgaviXmlConfigHandler
{
    // notwendige Methoden implementieren und XML-Struktur validieren...
}

Für Beispiele einfach in die in Agavi verwendeten XSDs und entsprechende ConfigHandler sehen. Viel Spaß. :)

Kategorien
ANT Deployment Linux Shell XML

Deployment mit ANT

ANT ist ein wunderbares Kommandozeilen-Tool mit dem man Deployment gerade auch von Webapplikationen automatisieren kann.

Ich benutze es um Entwicklungsstände in die Stage oder Liveumgebung auszuspielen.

Zur Konfiguration des Deploymentprozesses erzeugt man eine build.xml Datei, die alle nötigen Anweisungen enthält.

Folgende XML Datei erzeugt einen Backup-Ordner und kopiert die aktuelle Live-Applikation dort hinein.

Desweiteren erzeugt das Skript einen Datenbank Dump und kopiert diesen ebenfalls dorthin.

Danach wird der aktuelle Entwicklungsstand in den Live-Ordner kopiert.

Zu guter Letzt werden noch die Log- und Cache-Ordner geleert.


<project name="builder" default="build" basedir=".">
    <description>
        devel to live update including dbdump and clear cache
    </description>

    <!-- set global properties for this build -->
    <property name="devel" location="devel"/>
    <property name="live" location="live"/>
    <property name="backup" location="backup"/>

    <property name="db_host" value="localhost"/>
    <property name="db" value="databasename"/>
    <property name="db_user" value="databaseuser"/>
    <property name="db_pass" value="databasepassword"/>

    <target name="build">
        <!-- create the timestamp -->
        <tstamp/>

        <!-- create the backup dir -->
        <mkdir dir="${backup}_${DSTAMP}"/>

        <!-- dumb db to backup dir -->
        <echo message="create mysqldump"/>
        <exec executable="mysqldump" output="${backup}_${DSTAMP}/dump_${db}.sql">
            <arg value="${db}"/>
            <arg value="-u${db_user}"/>
            <arg value="-p${db_pass}"/>
        </exec>

        <!-- copy current live dir to backup dir -->
        <copy todir="${backup}_${DSTAMP}">
            <fileset dir="${live}"/>
        </copy>

        <!-- copy current devel dir to live dir -->
        <copy todir="${live}">
            <fileset dir="${devel}" excludes="**/*index.php"/><!-- beware overiding main config index.php -->
        </copy>

        <!-- delete cache/log files -->
        <echo message="cleanup cache/logs in backup/live"/>
        <delete includeemptydirs="true">
            <fileset dir="${backup}_${DSTAMP}/application/cache" includes="**/*"/>
            <fileset dir="${backup}_${DSTAMP}/application/logs" includes="**/*"/>
             <fileset dir="${live}/application/cache" includes="**/*"/>
            <fileset dir="${live}/application/logs" includes="**/*"/>
        </delete>
    </target>
</project>

Dieses Skript wird auf der Kommandozeile von Linux ausgeführt.

ANT sucht per default nach einer build.xml im ausführenden Ordner.


user@server:~/pages$ ant

Buildfile: build.xml

build:
    [mkdir] Created dir: /home/user/pages/backup_20091027
     [echo] create mysqldump
     [copy] Copying 1153 files to /home/user/pages/backup_20091027
     [copy] Copied 261 empty directories to 5 empty directories under /home/user/pages/backup_20091027
     [copy] Copying 50 files to /home/user/pages/live
     [echo] cleanup cache/logs in backup/live

BUILD SUCCESSFUL
Total time: 27 seconds