This seems to be the pattern for Taco HTML Edit. I fix one bug just to find another. Well, I guess I'm slowly making progress. Sometimes, I wonder if the next version (which I think I'm calling 1.6.0) will ever be finished. There really aren't a lot of changes in this release. It colors PHP and has plenty of bug fixes, although its possible that I've introduced new bugs because much of the code has been completely overhauled. If anyone is interested in being a beta tester, your help is needed! Just leave a comment or send an email. By the way, being a beta tester means that you find problems (i.e. something does not function like it is supposed to) and report them to me. This is different from requesting features (no more features will be added to v1.6.0).

What's going on with Taco HTML Edit? Well, here's a look at one of the new features.

Alright. It's time for me to make some decisions about development projects. First of all, I must finish the next version of Taco HTML Edit soon. I need to try to get a beta out this weekend, after which I will not add any significant improvements before release, only bug fixes. Having said that, I am so far very pleased with the progress I've made in Taco HTML Edit. It is becoming a very mature product, both for users and from a developer's perspective. The source code is now much easier to handle than it used to be.

I now want to start going through my new book, Unix Network Programming. I hope that by mastering the material in this book, I will then be able to understand various online documentation and create some useful software. I think that I have the ability to make software that will improve people's lives. It's only a matter of time.

During the three day weekend, I have been working on fixing everything in the syntax menu of Taco HTML Edit. I'm basically consolidating some repetitive code. After this, it should be easier to fix bugs and add features. I'm running into some difficulties on how the HTML syntax checker should work. For example, consider the following code:

<a href="http://tacosw.com>Taco Software<a>

<input type="submit" name="submit" value="-->">

<input type="submit" name="submit" value="--&gt;">

Update: I just checked Dave Hyatt's Blog (Dave Hyatt is a Safari developer), and ironically enough, he mentions the exact problem that I talk about in this entry.

In a comment for "Progress Report", Josh said:

This pertains to your "annoyance".

I looked at my code today, and I see that I haven't done anything to add or strip slashes. So basically, as I've said before, PHP and mySQL works happily. So here's what I do.

When I input something into the database, PHP has already added the slashes. I have a verification page, in which I do a stripslashes on the passed variable. However, the database gets all the slashes and so forth created by PHP.

I realized today that I never dealt with this "annoyance" whatsoever, other than the fact that I don't remember at all when I even had this problem in my mind (even though I should have, like a good little programmer, such as yourself). But yeah, it's not a server thing or whatever (I was full crap), it is a PHP thing. It's not really an annoyance, but they just do it for you.

So here's my thing on the "annoyance". PHP adds the slashes, and mySQL just gladly accepts the incoming data (whatever it may be). When PHP drags that information out from the databse, PHP does it all on it's own, so that the user or the programmer doesn't have to worry about stripping or adding slashes. I swear PHP/MySQL must live as one! WOOOOOO!

The first point that I would like to make is that not all servers have PHP configured like Josh's server. For example, the Living Water server is not configured to automatically add slashes to inputted data, and I cannot (at least on my own) change this aspect of the configuration. As a result, I manually add slashes to everything. However, the Living Water server does automatically remove slashes, so I must not remove slashes when retrieving data from MySQL or else I might take away slashes that are part of the data. It appears to me that there are instances where even Josh would need to add slashes manually. For example, when Josh retrieves data from MySQL, the slashes are removed. If Josh subsequently wants to insert this data into some other part of the MySQL database (a procedure frequently used to associate data from different tables), he will have to manually add slashes.

However, the important issue here is not related to these details. The important issue is code portability. The open source movement is based on the fact that the same code does the same thing on different computers. Configuration issues like this slash "problem" mean that in order to write truly portable code, one must check the server configuration and respond accordingly every time that data is inserted into a database. Although a function can be written to handle this issue, it adds unnecessary complexity. After I created the Living Water login system, Josh told that the nice thing is that I can now use the same code for different projects. Some of that "niceness" is lost due to issues like this one.

Having said this, I understand the points that Josh makes about the convenience of having PHP do the slash work for you. In fact, much of my emotion on this issue probably arises from the fact that until recently, I did not fully-understand how PHP handles slashes, so I spent much time fixing code that wasn't quite right.

I think that I am done with the major changes in Taco HTML Edit 1.5.2. I want this version to undergo some significant beta testing before it is released to ensure the stability and accuracy of the new coloring algorithm. I also want to make sure that none of my bug fixes introduced new bugs. Anyone who's interested can let me know. I suppose that I can convince my roommate Alex to beta test. I'm sure that you will all be happy to know that this version will be the first to undergo any significant beta test period. Its about time that I start forming some good habits. ;)