akrish

I’ve already briefly highlighted akrish.net’s structure in my previous post, but in this one I’d like to talk about some of the design strategies that I’ve used. Since I’ve already talked about how I read files, I’ll spend some time to briefly talk about how I’m writing into my xml files.

The first good design tactic I used was object oriented programming. So it’s really easy to use OOP in Java and some other languages, but in PHP it’s not the first thing that most people think about (at least I don’t). Yet it’s still really useful, because it allows you to compartmentalize all of your code into neat little objects that you can pass around and use really easily. So I have two classes: a Parser class and a Writer class. Both of them are for handling interactions between the web site and the xml documents that I’m using for feeds. The Parser object is pretty much what I explained in the previous post, except that it’s now an object. The Writer object has a function that writes a blog post into a specified xml feed, and that’s pretty much all it does right now. OOP is a lot better than functional programming in this case for a couple of reasons. First off, in the Parser object, all of the functions deal with an xml_parser object and so require an initialized xml_parser. This is easily solved by just iniitalizing one in the Parser constructor so that i’m only initializing the xml_parser once regardless of how many times I need to use it. Similarly parser functions need to know what feed to parse, but with OOP I can specify the feed in the constructor, rather than individually in each function. It prevents a lot of repetitive code. Another reason is that I can serialize objects and maintain all of their data as the user moves from page to page. I haven’t taken advantage of this yet, but I’ll need to it to allow a blogger to preview his/her new blog post. Anyway using objects makes the code a lot easier to read/change.

I also made the site highly modularized and functional. In addition to the objects, I also have a lot of functions that spit out content onto the pages. For example I have helper functions that spit out the html for the header, footer, and the navigation bars for all of the pages. These are really helpful, because I only have to make changes in one place, and the changes are propagated to the entire site. Furthermore, there’s a lot less code and a lot of my files end up having very little code, making everything easier for me to read later on.

I’ve also made change to how I show each feed, after realizing that I’d made a huge mistake. I used to have a separate file to show each feed (not the parser object, but each of these files calls the parser object and shows the content of the feed). This turned out to be a huge mistake because each of these files were the same except for which file name they passed to the parser. Anyway making changes got to be really tedious, because I’d have to make the same change on each of the files. I fixed this by making my index.php display all of the feeds. It selects a feed based on a parameter sent by HTTP GET. This is a lot better design wise for reasons that I’ve already mentioned.

Finally, the writer object is pretty straightforward. I set up an HTML form that’s password protected, with fields for feed, title, and body of the post. When I submit the form, I pass all of these parameters into the Writer. The Writer uses some simple regex’s to split up the text and add the proper xml tags. It then reads the old feed, and inserts the new xml into the old feed in the right place. Finally it re-writes the entire feed. I don’t think this is ultimately the best way to do it, because a lot of stuff stays the same in the file, and if the feeds get really long (which they may), this process may end up taking a while. For now it’s ok but I’m going to think about a better way to write xml files.

So that’s pretty much how this site is written. I do plan to add support for more tags, for example Image tags and Code tags so that I can style code differently will probably be added eventually. I don’t expect the rest of the back-end to change much so this’ll probably the last big post about akrish in here. Most of the other posts will probably be about wenote or any other ideas that I decide to execute. If you have any feedback about my design or if you’d like to see some features added, please let my know by commenting or by Thanks.

Since about 4PM yesterday when I actually started working on this site, I’ve been thinking a lot about how this site should be designed and built. The initial idea that maybe a lot of newer coders have is to just hard-code everything. This would mean writing my entries in HTML documents, manually moving entries from page to page etc. It didn’t seem like a very productive way of doing things, which got me thinking about some other, easier ways.

I know that there are a lot of blog-hosting sites out there, so I started looking at them for examples. Obviously they don’t let their bloggers write their entries into the HTML. That just restricts the number of users they have to mostly coders. I realized they must have some sort of web form that allows users to make posts and that they probably have some backend script that reads in the data from the web form and stores it somewhere. This seemed like a pretty reasonable idea to me, not only because it would let me leave my code alone, but also because it would allow me to make posts at any computer using any web browser, whereas in the other model I’d only be able to make posts when I have ftp access to the files on my server. It’s also a lot simpler in that I can write all the parsing tools now, and then I don’t have to manually do anything except write my entry.

I decided that this would be a good way to go, but how would I store the data? I immediately thought about mySQL because I’m pretty familiar with it and it wouldn’t be too difficult to create a bunch of tables (one per category) and then store date, title, content of each story in those tables. I was confident that this would work, but I also thought about storing my data in XML. The XML way would involve one xml file per category, each with ‘story’ or ‘entry’ tags that contain the date, title, and content of the entry. I settled on the XML approach because I’ve been working a lot with XML on wenote (my other site that’s currently being designed) and at work, so I’m pretty familiar with it, and I know that it’s very easy to use. Another minor advantage is that I can easily write articles in here before I create my web form (described above) for making posts. For example, I wrote this article directly in my xml document, and even though I don’t intend to do this, it does make it easier for me to get the ball rolling on this site.

Seeing how this is my first blogging site, I don’t really know if this is a good design plan, but it seems like it’ll work. I’m pretty happy that I’m getting a lot better at thinking of alternative ways to design things, but I do need to think more about pros and cons of each idea before just jumping into one of them. I’ll probably take a look at some of the more popular blogging companies in the next few days and compare my design with anything I can see about theirs. I’ve got a pretty basic, prototype implementation up and running but I’m changing it all the time, so I’ll describe that once I’ve settled on it.