/**
 * assume that 'html' is the standard GET output for this action
 * when this action is called via POST you want to change the output type to 'json'
 * because on error or success you want to show small messages per json instead full html
 */
    public function executeRead(AgaviRequestDataHolder $rd)
    {
        return 'Input';
    }

    public function executeWrite(AgaviRequestDataHolder $rd)
    {
        $this->getContainer()->setOutputType($this->getContext()->getController()->getOutputType('json'));
        try
        {
            // do POST stuff
        }
        catch(Exception $e)
        {
            $this->setAttribute('message', $e->getMessage());
            return 'Error';
        }
        return 'Success';
    }

http://kohana-modules.com

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

github.com/webpiraten/xgchunker

https://github.com/webpiraten

Hier gehts zum Kohana Projekt

<!-- 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

<!-- cut out leading slash -->
<route name="slasher" pattern="^/" stop="false" imply="true" cut="true" />

<!-- match ajax calls with special http header -->
<route pattern="XMLHttpRequest" source="_SERVER[HTTP_X_REQUESTED_WITH]" stop="false" output_type="ajax" />

<!-- match json calls with special http header -->
<route pattern="application/json" source="_SERVER[HTTP_ACCEPT]" stop="false" output_type="json" />

<!-- cut out special pointer -->
<route name="portal" pattern="^({portal:[a-zA-Z]{3}}/)?" stop="false" imply="true" cut="true">
    <callbacks>
        <callback class="RoutingCallback" />
    </callbacks>
</route>

phphatesme.com – PDF Dokumente mit Zend LiveDocx

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ß. :)