Page 1 of 2

Growing a Hairball

Posted: Mon Oct 04, 2004 11:27 am
by ProjectPerko
This isn't really a plea for help so much as... a kind of plea for clarification.

Okay, I tackled a rather oversized LAMP project without having any real experience with any part of the acronym save 'L'. However, after much research and programming and reprogramming, I created a solid code base that uses a... unique approach.

My problem was that I needed to have extremely adaptable code - able to call upon any table in a database for entry, scanning, printing to calendar, etc... all while being extremely user-friendly. So I couldn't create PHP code for each, of course - that would have created fragile code, and I needed extensibility. I had to create PHP that would create the HTML and take in the HTML form response... but even then, I couldn't create the PHP for each possible action, because it would be fragile and difficult to extend. So I had to make PHP to create response PHP for each page as it came up.

The problem I ran into was that if someone clicked on a button, it referred them back to the main page, where the PHP to execute didn't exist. After struggling for a while, I decided to store the PHP for the buttons in their user profile, in the database. Every time they visit the page, the code executes, checks to see whether the applicable buttons have been pressed, harvests the HTML, and does what needs to be done.

This has upsides and downsides, but it seems to me to be fairly counter-intuitive. I was wondering how people normally solved this issue - the tutorials I found were always linking to other pages or doing things that were extremely simple, so they were no help.

-Craig

Posted: Mon Oct 04, 2004 11:33 am
by feyd
I believe situations like this use [devnet]DAO[/devnet].

[big_search]DAO[/big_search]

Posted: Mon Oct 04, 2004 11:42 am
by ProjectPerko
I'll read up on it, thanks.

Side note: you joined in March, but already have 4770 posts? That's incredible.

-Craig

Posted: Mon Oct 04, 2004 11:43 am
by feyd
I post/know too much :D :P :lol:

Posted: Mon Oct 04, 2004 11:53 am
by ProjectPerko
By what I see, DAO (Data Access Object) is simply a method of communicating with the database. I'm using ADODB for this, and it seems to be working fairly well.

The issue I had was that I was creating web pages - on the fly - to address any table in the database and manipulate it in any way I needed. Essentially, I had to create a "VO" (Value Object). But I needed to create one which could address any table I would ever care to add, automatically adjust to handle modified table, interpret data into a useable form, allow or prevent access based on permissions, display merged tables, etc.

I couldn't create a page for each action, or even PHP for each action, since the actions were functionally unlimited (they would grow over time). I instead created PHP that created PHP for each action, which I then stored in the database as required for later execution. I was wondering if anyone had encountered this kind of issue, and if they had any ideas as to other approaches, since this one has a few drawbacks.

The reason I ask is because I have to (suddenly) add a whole lot more functionality, and I wanted to see if there was an easier way to do it. Previously, I had to edit tables only in certain ways, but now I have an extensive list of methods... it's going to turn into a hairball.

-Craig

PS: Check your links, feyd.

Posted: Mon Oct 04, 2004 11:57 am
by feyd
The DAO's I've seen create completely dynamic objects based on the table you ask them to load. They build and execute the queries to any capacity you wish and such. It sounds extremely similar to what you created.

They links are generated automatically from a tag we've added here. It's a dumb tag, to keep the speed up.. obviously most of the locations don't have any data on it.. or it matches too many things Dao for instance :P

Posted: Mon Oct 04, 2004 12:00 pm
by ProjectPerko
Could you provide a cite to the DAO you've seen, please?

It appears that my DAO is not the true DAO... :roll:

-Craig

Posted: Mon Oct 04, 2004 12:13 pm
by feyd
there was a long thread a ~short time ago about it, lemme see if I can find it...

hmm.. I can't quite find it.. although I know Heavy (username) was a major poster in the thread. I hope it wasn't deleted in the forum crash a few months ago..

Posted: Mon Oct 04, 2004 12:39 pm
by ProjectPerko
viewtopic.php?t=21887&postdays=0&postorder=asc&start=0

If you mean this thread, then yes, it does apply somewhat to my needs. My solution is in many ways quite similar to Heavy's (not LiLpunkSkateR's). I too use eval(). (Old LISP habits never die!)

However, unlike Heavy's, my eval cannot be replaced with regexp, at least not without literally hundreds or thousands of lines of additional code to re-interpret regular expressions, translate them into PHP (or call PHP segments), and then execute them. And then I would still have the same problem: I would have to store the regexps in the DB and call them up to be 'executed'. After all, this isn't just a front-end style sheet I'm creating.

-Craig

Posted: Mon Oct 04, 2004 12:47 pm
by feyd
nope, it wasn't the templating engine thread.. although kinda sorta similar.. I don't remember who started it, but Heavy talked about a set of classes and things he's built, and another poster built something similar.. that bunches up an entire table (not necessarily all the data, mind you ;)) into a simple interface class. From what I remember, it was quite simple to create very complex queries with it, although it has been a while since that thread was last posted to..

Posted: Mon Oct 04, 2004 12:55 pm
by ProjectPerko
Although I would really like to see that thread so as to compare to my own code on the subject, the difficulty I am having is in the PHP reponses to such a creation. For example: I have a table that can be, depending on a user's access level, edited in three totally different ways. It's easy to make the HTML for each of these, but the responses are more difficult, because as far as I can tell there are only two ways to do it:

Hardcode the PHP responses for each button into the file. This means that a spoofer can 'press a button' even if he doesn't have it on his HTML by emulating the HTML result of pressing the button. So you have to carefully check and make sure the button is allowed to be pressed by that user at that time. It also creates a vaste PHP wasteland of 'was this button pressed?' conditional statements... an utterly fragile and space-inefficient method.

Create the PHP responses on the fly as the HTML button is created. Then a spoof would do nothing, because that PHP just doesn't exist. Unfortunately, the only method I found to store this PHP so it can be executed when required (as opposed to immediately, before any input is made) is by storing it in the database under the user profile. This has a few small drawbacks (like sessioning/cookie issues... :? ) but has worked over all.

I wanted to compare and contrast to any methods others have found.

It feels like I'm utterly failing to be clear on this. :D

-Craig

Posted: Mon Oct 04, 2004 1:05 pm
by feyd
No, you're not failing in communicating that.. at least to me. I was trying to offer (with craptacular success) the information of how Heavy implemented his idea of how it can be done.

One thing that does pop to mind is instead of storing the code (which I'm guessing is nearly duplicated for each access level), you could add the code entries (when needed) to a "code" table, using some hashable string (passed through [php_man]sha1[/php_man]() or [php_man]md5[/php_man]() perhaps) to create unique identifiers to the code blocks. Personally, I'd create this hashable string from the list of things posted to the script combined with the user access level (either in the hash string, or stored in a seperate column). With this form, you can cache most of the code needed nearly immediately. And only the first few uses of the script should cache the rest of the code needed..

Posted: Mon Oct 04, 2004 1:21 pm
by ProjectPerko
Interesting. Lets look at an example. I have a table of N entries for things currently on loan. One major function for this would be to display all the things currently on loan (and any pertinent data), as well as a 'returned' button next to each. Once pressed, the item is marked returned/available, and it is no longer displayed on that particular page. As well, any item that is modified to be taken out (on another page) shows up here.

Currently, any time this page is called, I create the PHP code for each button (which is two lines for each button and maybe seven or eight lines max to make all the buttons). Since this is deleted as soon as that user does anything else, the button-specific PHP is destroyed, and does not bloat the table. (By the way, this is the major downside. If they surf to somewhere else in a new window, such a calendar view, and then come back, the PHP is gone, so none of the buttons work. I would LOVE a way around that.)

If I used a hash table like the one you suggest, the table gains a new entry each time anything is returned or borrowed, or at the very least is recalculated virtually every time. What benefit is there to it, then?

-Craig

Posted: Mon Oct 04, 2004 1:28 pm
by feyd
I wasn't talking about the values as this hashstring, I was talking more about the variable names themselves, along with the "page" name, and a few more generic type things. Because the generics of that alone will probably tell your script what code it actually needs to generate.. I'd look at trying to break everything down into the most generic of things you can classify them as.. the hash could just be the table to use and the access level of the user, that alone would often be enough (along with getting the table structure you probably do already anyways) to have your builder script generate the code needed.

Posted: Mon Oct 04, 2004 1:39 pm
by ProjectPerko
I see! That makes sense. But then what about multiple users, since I have 80+ users who all tend to use the system between 6-8 AM and 3:30-5:30 PM. If two of them load up a page (getting HTML), but then one of them clicks the button (changing the page)... then what happens to the other user, who still has the old HTML but is functioning with the new PHP code?

This is worse since many of the pages depend on many other pages, so one change would alter the PHP for three or four pages.

-Craig