> Hello Jörg,
>
> three questions -- there already seems to be a GX framework for JS
> animation:
>
> http://gx.riccardodegni.net/
> http://code.google.com/p/gxframework/
>
> Aren't you affraid of namespace clash?
No. The name collision is unfortunate, but shouldn't be a problem since the
two frameworks do very different things in two different programming languages
- there isn't much room for confusion IMHO. Besides that, the JS project
hasn't seen an update for two years now (correct me if I'm wrong), so this
should be a non-issue.
> The tutorial is nice but it's mostly a get-mod_perl-running tutorial
> -- the resulting application is what seems to be just a static
> welcome.html there. Any more complex example application, showing
> some Perl code executed, and database accessed? The GX man page it
> lacking the relationship explanation as well.
You are right. There is no end user documentation at the moment (and almost
certainly won't be for the next couple of months). I probably should have
chosen "Looking for fearless pre-alpha-testers with too much free time on
their hands" as the subject of my original post. The API reference, however,
is pretty much complete - but, as you said, it doesn't connect the dots yet.
If you (still) want to play with GX, I suggest using the bootstrapped
application (from the tutorial) as a starting point. Try modifying the
default() action in the application's Root controller for starters. Since
everything in a GX application revolves around the context object skimming
over the GX::Context POD is probably very insightful. The GX::Controller POD
contains some basic examples on how to declare routes, use filters and define
(custom) renderers for your actions. Unfortunately, it doesn't explain the
automatic template rendering mechanism yet. But it works as expected: Simply
add a template file to your application's templates/ directory and GX will
render it automatically (if a corresponding action exists). The test
application in t/GX-Controller/06_rendering/data/ gives an overview of the
possibilities (formats, multiple template engines). Looking at the other test
applications in t/GX-Controller (and in t/GX-Context) is probably helpful too.
To use the GX database API, simply create a database component (module) and
add it to your application's lib/ directory. Just take a look at the synopsis
of the GX::Database subclass you want to use (e.g. GX::Database::Pg). To get a
(cached) database handle, simply call MyApp::Database::Foo->dbh().
> Can you provide some high level comparison to (say) Catalyst? Surely
> there was a reason to come up with yet another web application
> framework, so what are the selling points?
The main selling point would be that GX is designed for persistent
environments (mod_perl or FastCGI). GX preloads, precaches, prerenders and
precompiles as much as possible as soon as the application is loaded/setup.
Besides the performance gain, this has the additional advantage that many
common errors can be caught at setup time (e.g. a bad route or a missing [%
END %] tag in a .tt template).
Another major selling point would be the reload mechanism. When running in
development mode, a GX application automatically reloads itself whenever one
of its components (or templates) is changed: No need to restart the server.
GX is also highly modular and very easy to extend. A GX application is
basically a sequence of hooks. The application's components/plugins add
callbacks ("handlers" in GX terminology) to those hooks. You can add/remove
hooks/handlers as you like, which makes customizations/optimizations (and also
writing plugins) a breeze.
GX also offers a database connection cache, a highly customizable rendering
mechanism, powerful flow control options, out-of-the-box session management,
informative exceptions and, last but not least, a clean, consistent API.
But again, this is a pre-alpha release. I'm just looking for some feedback and
maybe a few fearless testers. I'm sorry for not making that clear earlier.
--
Jörg A. Uzarek
runlevelnull.de
