Propel Stuff

I have spent most of this last week fiddling with Propel trying to get it to suite my needs. Overall I would have to say it’s worked pretty nicely. There is some quirks about it that I absolutely can’t stand. Since no one is in their channel on IRC I figured I would just write them down here in the hopes that someone, someday, that knows something about the internals of Propel can help me out.

For those that don’t know what Propel is: Propel is a full-service object persistence and query toolkit for PHP. I use to use my own library for object persistance, but I just no longer had the time to develop on it and propel did everything I needed much better. (For instance, my library wouldn’t generate my stubs for me :(.)

I have several different applications that I do constant work on for this example I will use two of the applications, one of them is a product catalog and one of them is a CMS system. In many of these application, there are several domain level objects that are actually shared throught several applications. One of the objects that are shared between my cms and my product catalog is a database I use to hold media file data (images, flash, pdf, word docs, anything really.)

I like to keep most of my domain level classes (with the exception of a
few extremely specialized ones) in a central location on my production
and dev servers. This media object is one of them. If I make a change
to my media object to allow for some more meta data to be associated
with each object I want these changes to effect all applications that
use this object. If I all of a sudden want to add thumbnail support to
my media object (it’s already there btw, just using it as an example.)
I don’t want to have to maintain seperate copies of a media object to
allow this.

Now, the way the propel generator works, is it allows you to generate source code for database schemas that are defined in xml files. It gives you some degree of organization to the resulting classes by allowing you to assign databases, or even tables to specific packages. The resulting code is then seperated into directories with the same names as the package. So I have accordingly used this to my advantage. I have one package called medialibrary that contains the object classes for the tables required by the medialibrary. I have another package called productcatalog that holds those classes. I of course don’t include the medialibrary classes in that package as really they are more of an ‘add-on’ to the product catalog (granted, very few people would want a media catalog with no pictures :P.)

In order to prevent my schema files from being inordinately long and to keep the generated sql files somewhat specific to each application. I have a seperate schema xml file for each package. However, obviously some of the tables from the productcatalog package are going to need to link (foreign keys) to tables from the medialibrary package. Thankfully there is a tag supported by propel called <external-schema> which allows you to pass a filename to another schema file as an attribute. The generator will then open this schema and use it as a reference to figure out what functions are needed. However, whenever a group of tables is opened via external-schema, the package names are overwritten! Which mean all of the classes in my productcatalog package that depend on classes in the medialibrary package are attempting to load them from the productcatalog folder. I can’t figure it out.

So, if you know alot about propel and can help…please oh please oh please leave a comment.

New ‘AJAX’ Tutorial, ala Joshua Eichorn

I just got done reading through this post by Joshua Eichorn. It is a nice little tutorial on how to set up and create a small little app with HTML_AJAX. Unfortunately for me I just started using JPSpan and have finally gotten use to all of it’s quirks. So I probably won’t change anytime real soon. I’m definantly putting it on my list of things to explore though. If you know JPSpan well, from what I can tell you could figure HTML_AJAX out very quickly. It is extremely similar.

Maybe after I get some breathing room I’ll do a full review of HTML_AJAX.

For those that just want to know a little more about the latest technology to be named after a cleaning product, Joshua has alot of excellent AJAX resources on his site and linked to from his site.

var_export/print_r

Ilia Alshanetsky posted this a few hours ago on his blog:

Security Implications of var_export/print_r

It basically talks about how allowing user supplied (POST, GET or even COOKIE really) posts to be saved to strings via var_export and print_r can be hazardous to one’s server’s health.

I hadn’t thought about this in a long time. I ran into this when I used smarty for the first time. I had inadvertantely passed a rather large object with quite a few references to other objects to the template, so when I tried to enable smarty’s debug feature, it choked on me cause I went passed my memory limit. (I think it was still at the default at that time: 8MB)

I think this post, yet again, shows how important it is that user supplied data gets filtered. I just read an article Ben Ramsey wrote for PHP|Architect’s latest issue regarding input filtering. It’s actually the first part of an ‘n’ part series so it didn’t really get into alot of the meat. However he makes some really good points about why input filtering is needed and gave an overview of a couple principles to use when filtering input. If I recall right, Chris Shiflett also has a small bit on input filtering in that issue too. So i would recommend picking it up if you have some spare change.

Thinking too much

I have spent the last couple days of my life observing and occasionally lending a hand in some of the php channels on irc.freenode.net. While I was watching questions and answers fly by in #php I observed something peculiar that has now led me to this thought: One of the biggest problems many new PHP Programmers face is that they completely overthink their problem.

What I mean by this is that they have a tendancy, when they run into a new problem, to quickly think of a single possible solution, and then before coming up with a few alternatives they just dive headlong into that solution. After thinking about it a little longer I also realized that more experienced developers have the exact same problem. I’ll get to that in a second. First I want to talk about the events that led me to this conclusion.

For instance, someone asked the following question: Is it possible to suck jpeg data out of a database and display it in a webpage without saving the data to a temp file? Now, first off most of would probably say "why would you want to do that? It slows down your db! Save the image to a file, reference the filename somehow in your database and then create a script that will just pull the filename out of the database and pass thru the contents. That reply however would be completely countertuitive to my example and I don’t want to go dig through logs to find another one.

So, in my fantasy world where we are not going to tell him that he doesn’t want to store the image in a database we would tell him this: "Sure, just create a seperate script that will accept a record id, have it load the image field from that record and pass the results with an image/jpeg header.

Well…here is what happened. The guy asking the question is Q, the guy(s) answering are A<n> (n denoting the different answerers)

Q: Is it possible to suck jpeg data out of a database and display it in a webpage without saving the data to a temp file?

A: yes, store as a blob. then re-create the headers using php’s header()
A: I do this for dynamically generated pdf’s…but same for graphics

Q: thanks. I tried that, but I only get the image.. What I want is to embed this image in html. When I use the header method it doesn’t render the rest of the html.

A: like inline mime images?

Q: yea, I guess. You know, have some text, tables, and then this image that I sucked out of the database all on the same page.

A: so you want the image data embedded in a single html output?

Q: yes, if possible. I guess I could store the image data in a tmp file then use <img src> but I was hoping I could do it without using tmp files. do you know if this is possible?

A: I’m pretty sure it’s possible…with modern browsers. but pretty rare to inline images like that

At this point another guy jumps in to lend a hand….we will call him…A2

A2: you can’t mix text and image data in the same docuement, without using browser specific tricks

Q -> A2: ahh, okay

A2: your best bet is to have a sepeerate image "proxy" poage, that you simply call with parameters to return n image. like image.php?imageid=102

A: best to just use sessions and pass stuff to an image gen script

Q: Hmm. I can probably do <img src=’createImage.php’> and then output the headers and data in the createImage.php file.

At this point everybody tells him yup, that’s what you want to do, he then says thanks and accuses himself of having a ‘brain hiccup’

So, from what I gathered of the situation it almost looked as though he knew what the solution was…he just kept on subconciously blocking it out so he could figure out how to literally embedd the image within the page. At first I thought, rookie mistake. Then I realized I am guilty of the same thing sometimes. Granted I don’t fret over things like how to display images effectively. However, I probably have at least a few more years of experience under my belt. He’s probably just getting started, so it’s perfectly acceptable for him to have the question of how to display images the best. I tend to make my overthinking mistakes on a much more grandios scale.

One of the biggest problems we have when it comes to overthinking is we overthink how we can shoe horn the latest, hippest, new technology into our projects. When SOAP got big I actually contemplated creating a central e-commerce service for all my customers that all of their websites would use. So instead of having a seperate database and deployement for each client I would have a centralized database with a single domain layer deployed and made accessible via SOAP. Then I would recode all my client sites to use this SOAP interface. I even came up with phony excuses of why this would be a great idea for my clients. Things like, "I could set up a profile system so visitors would be able purchase something from one site and if they wanted to save their billing and shipping addresses they could and then they could load it when they visited any other client’s site." What I was ignoring was the fact that every single one of my clients at that time were small to medium local businesses that had pretty much nothing in common with each other. I very nearly scrapped working code for roughly 20 sites to create an ugly, ugly solution that wouldn’t do anything better and would probably do alot worse.

Now the newest thing is AJAX, and we are all again scrambling to figure out, "how can I use that in my code?" or more appropriatly for some of us "how can I use this in ALL of my code?" Now, don’t get me wrong, I like the whole AJAX concept (hate the name…even if it’s very…clean) and I like the whole SOAP concept. My point is that us, "bleeding-edge" developers have the tendancy to try and fit all this technology in alot of places where it probably doesn’t belong.

Now, to try my best and bring this full circle. If we didn’t concentrate so much on new technology maybe we wouldn’t have all these "pushing square pegs into round holes" problems. I am now resolving to give equal thought time to both new technology and the old ways of doing things. Like some wise man once said, "Moderation is the best medicine." New technology isn’t bad, but old, proven technology is pretty darn good.

So, am I crazy, justified, or just plain stupid?