[geeklog-devel] Geeklog 2 Framework Code in Action

[Blaine Lang]

Looks good Tony .. and I will try to get it installed over the next week to 
check it out.
It certainly looks like a lot of work has been completed.

Cheers and I'll let you know how it goes.
Blaine
----- Original Message ----- 
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-devel at lists.geeklog.net>
Sent: Thursday, December 02, 2004 10:41 AM
Subject: [geeklog-devel] Geeklog 2 Framework Code in Action


For time sake I have attached the code I have already.  The code is for
a sample Hunting Log Book application. It has a little bit of everything
but is far from complete.  I'm sending this because Vinny is chompin' at
the bit to get started.  I wrote this sample application to demonstrate
a few things:

1) use of MVCnPHP and how it allows us to generate small, atomic and
easily managed code.
2) use of Propel...without it the code would be at least 300% bigger
3) use of a Data Access Object.  This object uses propel and hides the
propel details from the developer for the most part.  Thus GL2
developers should have to write very little SQL
4) use of named queries
5) use of the PEAR::HTML_Template_Flexy engine
6) concepts on how to do data validation and formating in this new
paradigm.  I'm not 100% satisfied with what I have but it is a step in
the direction I think it should go.
7) This shows the use of a List Of Values table.  It is a single table
that can be reused to multiple times for look up values.  This is
probably something many of you are familiar with but I wanted to point
this out because it reduces the number of data structures we'd need
considerably since look-up tables can now all reside in a single table
structure.

As you view this, *please* ignore the layout...I'm not a layout guy.
Here are the things worth noting.

First, don't look into the underlying framework code too much until you
get a feel for the basic code.  Specifically, your first gander should
focus on code in the following directories:

/path/to/HuntingLog/commands
/path/to/HuntingLog/views
/path/to/HuntingLog/templates

That's where the magic happens.  The commands and views directory are
where the MVCnPHP commands and views go respectively.  Take time to
notice and, hopefully, appreciate how little code exists in many of
them.  Granted my sample application is quite trivial, but try and draw
comparison's to how much code you would write to do the same thing with
the 1.3.x code.  After you do that, there are some abstract classes in
each of those directories that so some basic setup stuff.  You should
look into those and understand them as we'll need to

The templates directory is where the Flexy templates go.  The layout I
have defined in this app doesn't support the notion of a theme...I can
add that later with little trouble as it is just a matter of how we want
to layout the directories.  I haven't exercised all the features of
flexy in the views I have but it does do the most common things.  Flexy
works quite differently from PHPLib that 1.3.x so I would read up on the
documentation for it.

You'll notice this code in the commands and views have absolutely no SQL
in them.  Propel should generate 90% of the SQL and the other 10% must
go into the /path/to/system/Data_Access/NamedQueries.xml.  I'm sure
there will be a debate as to why all custom SQL must go in an XML file
so here are a few reasons:

1) Cleaner code in the commands/views.  It isn't muddled with SQL
2) Having the SQL in a single file allows us to reuse queries and gives
us a single place for making modifcations should the DB structures change.
3) The biggest benefit which isn't implemented yet, is that I can use
the queries in that XML file and generate a single PHPUnit2 script that
would regression test all the queries with a single command.  This is a
huge time saver in the case where we have massive structure updates that
will undoubtedly happen during alpha development.  Again, this isn't
implemented but I'm working on it now.

Also missing from this implementation is the ability to allow more than
one query XML file.  This will be required for plugins as it will allow
them to manage their own file for named queries seperate form those used
by the core GL2 kernel.

Here are the crude instructions for installing this. NOTE: Phing is not
required but Propel is because I haven't packaged the code into this
tarball. In the first GL2 alpha we'd obviously fix that but I don't want
anyone freaking about about requireing Propel.  Oh, and you'll notice
Propel requires Phing...this is only for doing builds.  I've already
done the build for the app in this case.  If you want a copy of this
tarball modified to include the Propel code please let me know...I'd be
more than happy to do it since installing Propel can be a bit tricky.

1) Make sure you have PHP5 ;-)
2) unpack into webtree
3) Make sure you have a version of MySQL that supports INNODB and
foreign keys.
4) create a database for this sample app
5) Import /path/to/HuntingLog/data/create.sql into your database
6) edit config.php to match your system
7) edit the database settings in
/path/to/HuntingLog/system/Propel/HuntingLog-conf.php
8) Now open browser and point it to index.php

Please only review it for the features I have noted.  This is meant to
be a throw away prototype and I assume we'll make many changes in the
short term to the framework.  By all means fire over any questions.  If
you have no questions but get it installed successfully even letting me
know you got it installed would be nice.

--Tony