As mentioned in my previous post, I'm still working on the Mencoder GUI, but it's now beginning to take shape. I've almost completed it (except for saving and loading profiles and the actual encoding part). All the codec specific/video filter configuration dialog boxes are complete as of now.

Here's a screenshot of the main window. More coming up later.

If you've been wondering why I've been so quiet on my blog, it's because I'm currently programming a mencoder GUI in Python using Tkinter as the GUI toolkit. The choice of Python with Tkinter makes this GUI as cross-platform as possible.

Why another GUI front-end for the mencoder video encoder, you might ask? Well, I wanted to improve my skills in Python, but I also wanted to write a GUI for mencoder which allows setting the video and audio codec options for the popular video and audio codecs (lavc, xvid, mp3lame, toolame, etc.)

It looks really simple at the moment, as most of the work is in writing the GUI code and translating the user-entered options into the respective command line parameters. Obviously it would be near impossible to encapsulate *all* of mencoder's available options, but I'm trying to keep it as friendly as possible.

Having used PHP as the logical choice for web development, I've always been a little mystified by cgi-bin scripts and never bothered to learn how they work. But no longer.

CGI scripts are nothing but scripts or executable programs. Apache simply executes them and renders the results. Of course, because every CGI program is an external application and requires the web server to start a new process, it makes the whole thing very processor intensive. The modern method of embedding scripts in web pages (most popularly PHP/ASP) which can be directly interpreted by Apache is a far more efficient method and I suppose more logical from a web designer's point of view.

However, there are still a few advantages to CGI scripts: you can use whatever language you wish to (plain shell scripting, Perl, Python and even compiled C executables). This offers many more options to the developer. Also in many cases CGI scripts are not limited to server "modules" and can directly use the underlying Operating System's functionality.

Rather than reinvent the wheel however, I'll point you to Apache's CGI tutorial which is a must read for any webmaster, web developer or server administrator.

Yes, CGI can be intimidating and complex CGI scripts can be a headache to maintain, but it's nevertheless useful to have an idea about how they work since so many websites still utilize this method of delivering dynamic content.

As I was in the middle of programming my new blogging system a few days ago (the PHP/SQLite one), I decided to go with Smarty, a PHP templating system which allows programmers to separate content presentation from the application logic. In its simplest form, a templating system provides a mechanism which allows you to define "tags" within HTML files which can be replaced by data generated by PHP code. But Smarty goes way beyond that and allows you to manipulate complex documents with relative ease while keeping the PHP functions separate from HTML code. Here are some of the pros and cons of using a PHP templating system. Keep in mind that using a system like Smarty is a highly addictive way of developing applications because it makes things so simple from a programming perspective and makes your code highly readable. I suspect though that it does have a few drawbacks as well. Here is my opinion on using a templating system as opposed to intermingling PHP tags with HTML.

Pros:

• Makes application logic much easier to follow and PHP code much more easier to read.
• Allows you to "skin" your website by using multiple templates. Thus the way your data is displayed is completely in the hands of designers who need no knowledge of PHP code to change the appearance of your application.
• Provides a shorter development cycle. It also allows you to plan exactly how your data should be extracted from source. It makes visualization of your application much easier by providing you quick, alternative views of presenting your data.
• Obviously it allows separation of skills as I mentioned above. A team of developers can be clearly separated into the "programmers" - the ones in charge of the PHP code, and the "designers" - the ones who actually lay out the presentation of the data.
• Using a third-party templating system is a good way to avoid "reinventing" the wheel, thus speeding up development time considerably. It also ensures that you need have no worries about maintaining the template library yourself.

Cons:

Yes, there are some cons of using templating systems as well. Here's what you have to watch out for:

• Processing of templates is an additional overhead you might wish to avoid. In spite of "fast" template parsers around (and Smarty is one of them) they still process text files in the ultimate analysis and any extra file processing increases execution time marginally.
• Sometimes you encounter situations where the application logic can simply not be separated from the content presentation. Yes, this does happen in practical development although finding examples theoritically is tough.
• Template designing can become extremely time-consuming because you are tempted to constantly refine and tweak the content presentation (because it's so easy to). As a result, if you are an individual programmer, you will find your priorities constantly shifting between coding and template development. This can be wearisome, since it involves working with two sets of files and you constantly need to co-ordinate your data fed by the PHP code with the template code.
• Using a templating system in the middle of a project forces you to rewrite or even discard large chunks of your existing PHP code. Even if you strip out all the HTML from PHP, you would need to write a set of "feeder" functions which would allow you to submit the data to the templating system in a format that it can understand. (currently I am forced to consider doing this, since the admin panel of my blogging system is completely written in the old style - PHP intermingled with XHTML).

That's all. Whether you use a templating system or not really depends on how you visualize the development of your application. Monolithic or small projects can get away with intermingling PHP with HTML code, but even with a moderately sized PHP application, you would be forced to think of ways to minimize PHP embedded in the HTML files and so you would have to write your own library of "feeder" functions which insert data into HTML. So why not use a pre-existing library which not only saves you that task right off the bat, but allows gives you a lot more features and flexibility to work with?

So remember, if you are ever planning to develop a non-trivial PHP application involving a bit more than simple content display, make sure you have a plan in hand to separate the content display from the application logic. It will save you a lot of headache later.

While I was writing the code for my new blog/CMS system yesterday, I realized why people prefer blogs to Content Management Systems and why developers prefer databases to XML for content storage.

To answer the first question: blogs enforce structure on websites which makes it very easy to insert content. By providing a convenient method of organizing information without requiring too much input from the end user, blogging platforms are way friendlier and easier to administer/manage from the back-end.

CMSes are unique beasts. They have a layer of abstraction that requires the end user to think a lot more about the structure. Even a simple CMS like Drupal forces you to think about content organization. While Drupal can be used as a basic blog, I think the point is that it is so flexible in terms of content organization that it does confuse one as to what is the best or optimal way of using it. That, I think is the crux of the issue. Thinking, planning and organizing a large website is a specialist design team's job. Blogging, on the other hand, allows people to create as much content as they want without having to indulge in structuring. Of course, categories and tagging allow people to manage content to an extent, but that is built into the system and so requires little maintenance. CMSes allow such flexibility in design that sometimes it's harder to think about how to manage content and to visualize how future content will affect a particular structure. They also carry a lot of features (or bloat, if you prefer) that are unnecessary for personal websites.

Coming to the second point, I think the reason why databases are more popular than XML with developers is something similar. Databases impose norms and rigid structure (fields and records). Of course, they are powerful because they can be queried in an endless variety of ways. But they scale well for small as well as large applications and it is easier to visualize how a database design will work with large amounts of data than to custom design an XML format that will allow future flexibility. I also think that with XML there's the issue of choosing a suitable XML parser for the particular application in question. The generic nature of XML parsing imposes a lot more pre-planning in terms of code, while it is a lot easier to write a specific set of SQL queries to work on a particular database that will completely manage data-handling for the application.

In the end, I think the answer lies in the fact that as people, we like structure and simplicity to generic flexibility and complexity in design. Structure doesn't necessarily mean rigidity while simplicity doesn't necessarily imply lack of features. It's the layer of abstraction that makes generic design (as opposed to one specific design) harder to visualize.