Thanks Paul and Renee!

Paul: I am not up to par on my SQL joins, I have to get another book this
weekend; I knew that joins would be almost necessary for what I'm trying to
accomplish. Iterative development, while painstaking, seems like the hands
on approach I'm used to, and has proven effective in the past when
developing complicated procedures.

On a side note: the application I am developing is turning out to be many,
many times larger than I anticipated, and I am learning OO concepts as I go
along. Occasionally I have to rewrite code, and take the opportunity to
improve in other areas (eg. I was using 2 versions of a session management
include, and when I moved to a new improved one I made sure every page had
another new include which defined a ROOT constant*). Now and then I take a
day to move iterative code into classes.

Renee: I think your idea of a superclass (hat-tip: Paul also mentioned an
inheritance approach) and child classes is going to be necessary. Originally
I was thinking of a "handler" class (all Reports) and a singular (NOT
singleton) class (a single report), but that led me to other questions and
distracted me from productive thought.

To be fair Renee, I couldn't follow what you were saying about your
newsscraper class (I've heard of curl, but not much more than that, and what
do you mean by 'parsing'?).

My application is meant to replace faxed order forms and Excel spreadsheets
(my associate does A TON of copy/paste when dealing with seat orders). So
this needs to be flexible enough to be a viable alternative. So far it is
far superior in many respects, but in others it is lacking. Liiike printing
out an excel spreadsheet is as easy as Ctrl+P, so to achieve this end I have
to generate a report for a bare bones html page to print.

SIDE QUESTION: What do you think of my use of serialization? I don't see a
need to store duplicate information in new tables, and thought serializing
these one shot reports the best solution.

Thanks again everyone!


*The include that defined a ROOT constant accomplished something I saw
someone else do, and it's genius (perhaps elementary to you experts). It is
so rudimentary I can't believe I hadn't thought of it: it searches for a
specific file "config.php" by using a while loop and the file_exists()
function, and on each iteration it adds a "../" to the file name
("../config.php" becomes "../../config.php") until it finds it (maximum of 5
levels up). Once it finds it, it assigns the "../" path to the ROOT
constant, so I can easily access my ROOT folder from anywhere in my script,
eg. <link rel="stylesheet" href="<?php echo ROOT ?>lib/css/layout.css" />

On Wed, Jan 27, 2010 at 9:57 PM, Rene Veerman <> wrote:

> Allen, i think your primary design consideration is this;
> ....
> > - Need to be able to build a large variety of reports based on existing
> data
> ....
> This would lead me to jump at a 'plugin' solution.
> I'd make:
> - 1 superclass as interface to the rest of your webapp(s)
> - 1 "top-class" that has the logic applicable to all reports.
> (or just 1 top-level class, if you want)
> - 1 to many plugin classes, that all use the same simple interfaces.
> By using arrays as options/return-results, the whole thing becomes
> extensible without breaking compatibility.
> I'm working on a newsscraper (same problem basically, doing both input
> to db and output from it) and for that i'm not even using classes. I'm
> using plain-old functions with a specific naming convention in files,
> also named according to a convention.
> Some examples of plugin functions exposed in '':
> function plugin__news__digg__pages($mp)
> function plugin__news__digg__isValidPage ($page, $pageContent)
> function plugin__news__digg__parser__siteHTML ($page, $pageContent)
> $mp = user-level parameters (from the superclass)
> __pages returns a simple array that tells the top-class which pages to
> curl (and with which parser-function (like __parser__siteHTML)),
> before passing $pageContent along with $page (a conventionized
> meta-data array, mostly built up by __pages) to the parser function
> __parser__siteHTML.
> All parser functions return an array that the top-level class can use
> to insert their "hits" into the db.
> Plugin functions can be called by $func =
> 'plugin__news__digg__parser__siteHTML'; $func ($page, $pageContent);
> In your case, Allen, i'd start with plugins that accept user-level
> parameters (both generic and specific in the same $options array, and
> to prevent confusion through feature-creep, use more than 1 level in
> the array) and then output HTML. Try to use CSS effectively.
> Using the smarty library in plugins' HTML generation functions is
> probably overkill, but some people like such midware.
> Your top-level class can take care of any caching of finished reports.
> Your superclass is responsible for building up the "frame" of the
> webpage that holds the reports.
> If two or more plugins need (almost) the same data, consider building
> a datastore class, that sits "below" all the plugins (and the
> top-class).
> And i highly recommend as the db-abstraction layer, to be
> used exclusively for all db access by all other classes.
> On Thu, Jan 28, 2010 at 5:20 AM, Allen McCabe <>
> wrote:
> > I actually started on a report class yesterday, and I have a few
> questions,
> > but first some details:
> >
> > - Reports will be on user orders (ticket reservations).
> > - Need to be able to build a large variety of reports based on existing
> data
> >  + Orders by a specific user
> >  + Orders for a specific product (event)
> >  + Orders by a user sub-group (organization)
> >  + Orders by a user super-group (school district)
> > - Reports need data from a primary table (orders) and several secondary
> > tables (users, order_lineitems, etc.)
> >
> > Now, I started to approach this with a class that builds an HTML table
> with
> > the data as the end product, based upon the parameters I supply.
> >
> > There shall be a table_header property which will be an array of column
> > names, a rows property which will be a bi-dimensional array which will
> > contain the data for each row.
> >
> > I want to have methods like the following:
> >
> > <?php
> >
> > $Report->createNew('orders', 35); // STARTS AN ORDER USING `orders` TABLE
> -
> > SHOW ID 35
> > $Report->addColumn('contact'); // USERNAME - `users` TABLE
> > $Report->addColumn('phone'); // USER'S PHONE NUMBER - `users` TABLE
> > $Report->addColumn('quantity'); // TICKETS REQUESTED - `order_lineitems`
> >
> > // SAVE OBJECT TO `reports` TABLE
> > $report = serialize($Report);
> >
> > $success = mysql_query('INSERT INTO `reports` (`data`) VALUES (\'' .
> $report
> > . '\') ;');
> >
> > if ($success) { $Notify->addtoQ('Report succesfully saved.', 'confirm');
> }
> > else { $Notify->addtoQ('There was en error saving the report.', 'error');
> }
> >
> > ?>
> >
> > I was having a tough time wrapping my head around how to make the report
> > class less specific and more flexible. For example, I have the user's
> > user_id already stored in the `orders` table (of course, foreign key),
> but I
> > want to display their username (or firstname, lastname pair), which would
> > require another call to the `users` table, so I had a $queries property,
> > which would be an array of queries to execute, but then I couldn't figure
> > out how to handle each one, because each is handled uniquely.
> >
> > So, I have to be less general, and more specific. Call what I want by
> > nickname, ie. $Report->addColumn('userRealName'), and have a switch
> > statement within the addColumn() method to check for nicknames. Whew!
> That
> > sounds awful!
> >
> > And how do I handle each result in the queries array? Should I create an
> > associate array (ie. 'username' => 'SELECT `username` FROM `users`....',
> > 'school' => 'SELECT `name` FROM `organization`... ') and again, have a
> > switch statement to determine how to handle the database result arrays?
> >
> > Can anyone point me in the right direction? Should I just get down and
> dirty
> > and write a focused class (or even procedural?) for different types of
> > reports that I anticipate needing?
> >
> >
> > This is a tough one! Thanks!
> >
> > On Wed, Jan 27, 2010 at 4:32 AM, Ashley Sheridan
> > <>wrote:
> >
> >> On Tue, 2010-01-26 at 18:54 +0100, PEPITOVADECURT wrote:
> >>
> >> > Exists any reports generator that exports directly to html/php?
> >> >
> >> >
> >>
> >>
> >> What do you want to generate reports on? I would assume this would be
> >> some sort of data from a database, and that you're looking for a
> >> PHP-based reporting tool that can output as HTML for viewing your
> >> reports in a web browser?
> >>
> >> Thanks,
> >> Ash
> >>
> >>
> >>
> >>
> >

Reply via email to