This has been a draft for a while, so things are probally outdated but I’m still wondering about this, so here goes…
I have been doing a lot more PHP lately then I have in a long while and that, plus the prospect of a pretty big project I will hopefully start on during the summer, made me think a bit about error reporting. I’m not talking about E_ALL vs E_, err, 0. I’m talking about what to tell the user when either (s)he or the application screws up.
Continue reading
Posted in PHP, Programming
Making something in PHP isn’t hard. Things get harder when it needs to be secure and when speed becomes relevant. But what to do when things really have to be at there absolute fastest? What if every µsecond counts? What if a single extra CPU cycle needed to run your script can cost a man his life? Read on.
Continue reading
Posted in PHP
I have been developing a while now, both as a hobby and education, and I see many people fearing that there database could possibly be a few MB smaller. So, when you talk to them about caching some data, they fear it would cause there harddrivers would get filled up way to soon. And, on one side, they are right; if you cache all your output, you could verry well end up having more space eaten up by cache then by the data and code used to generate it. And I agree, for most people thats not a verry good solution. You don’t want to store every possible output infinitly. So, how about storing the output for whatever gets requested, and leave it there for an hour (or any other amount of time, how long exactly would depend on the situation) and after that delete it? Or possibly leave it there untill there has been no request to it for some time? This sounds like a good idea, and it is for the more basic things. (In example, it is something I could implement on this site, on some parts) However, as soon as you start getting situations where people log in, this would mean a different version for each user, which is plain stupid. I personally do not beleave that caching everything is a good option, except for specific websites. I do, however, have a few ideas that I feel could improve preformance for quite a few applications I’ve seen.
Parsing user input into something showable is something most webdevelopers will, at one point, have to deal with. This is most relevant in forum software, so I’ll use that for example. I have a few running locally, and I mainly see three different ways to deal with it:
All three have there pro’s and con’s, some obvious, others only come to mind when you start thinking about it. I’ll shortly eleborate on all three approaches.
Parsing the data on request is, in my opinion, the most natural thing to do. Its also easiest, and its what most people do. However, it is also the most expensive. Because every time somebody looks at it, you have to run trough all the data, match it for stuff that needs to be replaced, make sure its safe to output. This all takes a lot of time, which we don’t want.
Parsing the data on submittion, on the other hand, is probally the cheapest thing to do. On first glance, its just as hard as parsing on request, except you only need to do it once. However, this had one major drawback: what if you want to edit the data? I gave it a try, and trust me when I say, un-parsing isn’t near as easy as parsing. Sure, HTML bold to BB bold is easy, but links are harder, and when you have more complicated stuff (like the /me feature that mimics what IRC does) it stops being fun.
Parsing halfway can be done in a lot of ways, but will mostly combine the disadvantages of both other options.
May I suggest what I beleave to be a solution to all the problems the previous methods cause, at the cost of just some diskspace: parse caching. (Ok, so I suck at naming things..) Its verry simple, yet I don’t think I’ve ever seen somebody do it. What you do is just parse the data when its submitted, but also store the originally submitted data. This way, there is no need to parse it every time somebody wants to see it, yet you can simply edit it be editting the original data and overwriting the parsed data with the parsed version of the new data. Alterantly, you could also parse the data when its requested the first time, and then store it in cache. In theory, that would save you the space the cache takes up for data thats never requested, but I think that in the real world, people will oftenly request the data they just submitted just to make sure its correct.
I think this read was long enough for now (I know the write was) so thats it for now, I’ll give you an insight into my brain again soon. 
Posted in Programming, The Internet
For a while now, I’ve been working on a framework that should, ultimatly, allow me to create a website by simply uploading the framework, modules the site needs, run a few installers and thats it. If it needs something I don’t have yet, I would be able to just write a new module without having to worry about things like sessions, users, etc, because the framework does that.
I did a few total rewrites, I’ve been verry unhappy about the way things work several times, but now I feel I’m really getting on my way.
There is just one thing left, really: A theme system. Its not that hard to just make a simple text-replacement system, but that just wouldn’t do. Partially because I want to give the person who makes it full control, so they need to be able to use PHP. And that, right there, makes it kinda hard. The theme/template file has PHP, so it needs to be parsed by the Zend Engine. (Sure, if I would really really really want to, I might be able to get the contents of the file, use a few dozen regular expressions, and be able to do basic PHP that way, but that would take ages to develop, ages to run, and would only allow basic PHP; I want it all.) However, when you do that, everything is outputted to the client (= whatever requested the page) rightaway, which I don’t want. (For several reasons. One being that I might need to set cookies, start sessions, etc after primary output. Another one is: The page title has to be partially set by the running module, but that would mean that the module is responsible for using the templating system, which I don’t want. All it should have to do is $this->engine->template(‘comments’);, and the framework would do everything else.)
Just now, I did find a solution: PHP’s output buffering system.
It wouldn’t be verry hard, I beleave. Consider the following function (as a part of the Framework’s engine class)
public function template( $what )
{
ob_start();
//
// The magic of grabbing the right file, executing it
//
$output = ob_get_contents();
ob_end_clean();
return $output;
}
This, right now, seems to be the way to do this. However, I have never worked with PHP’s output buffering, and thus, have no idea if this would actually work as I want it to, how it is on speed / memory usage, etc.
So I gues thats really the point of this blogpost (other then posting. 
), to find out of any of my nonexistant users is could give me some advice on the ob_ functions.
Posted in Programming