MacFUSE implements a mechanism that makes it possible to implement a fully functional file system in a user-space program on Mac OS X (10.4 and above).

In a nutshell, MacFUSE lets you turn any number of connection interfaces into a fully functional file system. With the files provided in the link above, you can mount an FTP or SSH login as a network drive, thus solving my issue of using subversion over a network drive. The best part is, I can now easily access my Mac Pro remotely as well. Although, now that I think about it, I have never tried to mount a remote drive over AFP so that could have always been possible.

I have to admit this is my new favorite development tool since it makes working remotely much more pleasant. Instead of opening files one at a time through Cyberduck, my FTP client, and Textmate, I can now mount my FTP account as a network drive and create projects with Textmate to edit all my files. This also happens to be a great solution for all the people wishing for FTP support within Textmate.

Anyhow, I hope this can be of help to someone else.

The only way I found to correct this problem is to add decorators to each element individually. This is highly redundant and hardly ideal, but it gives the control necessary to fix this problem. It also bloats the config file significantly; previously, the config was 31 lines long, but now it is 47 lines long:

[login]
; General Form Information
login.action = "login/submit"
login.method = "post"
login.id = "login"
 
; Form Decorators
login.decorators.elements.decorator = "FormElements"
login.decorators.table.decorator = "HtmlTag"
login.decorators.table.options.tag = "table"
login.decorators.form.decorator = "Form"
 
; Username Element
login.elements.username.type = "text"
login.elements.username.options.label = "Username:"
login.elements.username.options.required = true
login.elements.username.options.validators.alnum.validator = "alnum"
login.elements.username.options.validators.regex.validator = "regex"
login.elements.username.options.validators.regex.options.pattern = "/^[a-z]/i"
login.elements.username.options.validators.strlen.validator = "StringLength"
login.elements.username.options.validators.strlen.options.min = "5"
 
; Username Decorators
login.elements.username.options.decorators.helper = "ViewHelper"
login.elements.username.options.decorators.tableData.decorator.td = "HtmlTag"
login.elements.username.options.decorators.tableData.options.tag = "td"
login.elements.username.options.decorators.label.decorator = "Label"
login.elements.username.options.decorators.label.options.tag = "td"
login.elements.username.options.decorators.tableRow.decorator.tr = "HtmlTag"
login.elements.username.options.decorators.tableRow.options.tag = "tr"
 
; Password Element
login.elements.password.type = "password"
login.elements.password.options.label = "Password:"
login.elements.password.options.required = true
login.elements.password.options.validators.strlen.validator = "StringLength"
login.elements.password.options.validators.strlen.options.min = "6"
 
; Password Decorators
login.elements.password.options.decorators.helper = "ViewHelper"
login.elements.password.options.decorators.tableData.decorator.td = "HtmlTag"
login.elements.password.options.decorators.tableData.options.tag = "td"
login.elements.password.options.decorators.label.decorator = "Label"
login.elements.password.options.decorators.label.options.tag = "td"
login.elements.password.options.decorators.tableRow.decorator.tr = "HtmlTag"
login.elements.password.options.decorators.tableRow.options.tag = "tr"
 
; Submit Form Element
login.elements.submit.type = "submit"
login.elements.submit.options.label = "Submit"
 
; Submit Decorators
login.elements.submit.options.decorators.helper = "ViewHelper"
login.elements.submit.options.decorators.tableData.decorator = "HtmlTag"
login.elements.submit.options.decorators.tableData.options.tag = "td"
login.elements.submit.options.decorators.label.decorator = "Label"
login.elements.submit.options.decorators.label.options.tag = "td"
login.elements.submit.options.decorators.label.options.class = "submit"
login.elements.submit.options.decorators.tableRow.decorator.tr = "HtmlTag"
login.elements.submit.options.decorators.tableRow.options.tag = "tr"

Personally, I think this is poor design and feel it may even be a bug, but I will attempt to submit it to ZF’s issue tracker and see what they say. Otherwise though, I still feel as though Zend_Form is a great component, and will continue to publish any discoveries I come across.

login.elements.username.type = "text"

And turns it into:

Array
(
    [login] => Array
        (
            [elements] => Array
                (
                    [username] => Array
                        (
                            [type] => text
                        )
                )
        )
)

Now, back to Zend_Form. I think my biggest gripe with the documentation provided for Zend_Form is that it does not explain how anything is working behind the scenes. For instance, it does not explain that Zend_Form normalizes config statements by prepending ’set’ when making calls to member methods. This is invaluable as it explains why

    $form->setElementDecorators(array('ViewHelper'));

in PHP becomes

    elementDecorators.helper = "ViewHelper"

in a Zend_Config_Ini. Internally, elementDecorators tells Zend_Form to call setElementDecorators(); This small example also shows why it is important to know how Zend_Config_Ini actually translates an INI to PHP…

Array
(
    [elementDecorators] => Array
        (
            [helper] => ViewHelper
        )
)

As we can see this declares an array of decorators to be passed into setElementDecorators(); The keys, in this case “helper”, do not necessarily matter as it is only needed to index the array, the values are what matter, as that is what is passed and used within Zend_Form. Similarly, it is important to know that almost all aspects of form and form elements, excluding form element type, are implemented internally as options. The following is an example INI file with comments explaining particular sections.

    ; A basic Form config
 
    ; First level attributes are automatically treated as options.
    action = "login/submit"
    method = "post"
    id = "login"
 
    ; Form Decorators
 
    ; Again these decorators are treated as options of the main form.
    decorators.elements.decorator = "FormElements"
    decorators.table.decorator = "HtmlTag"
    decorators.table.options.tag = "table"
    decorators.form.decorator = "Form"
 
    ; Username Element
 
    ; Form Element Type is specified explicityly, not as an option.
    elements.username.type = "text"
 
    ; Username attributes (Label, Required, and validators are all
    ; declared as options).
    elements.username.options.label = "Username:"
    elements.username.options.required = true
    elements.username.options.validators.alnum.validator = "alnum"
    elements.username.options.validators.regex.validator = "regex"
 
    ; Validator parameters such as pattern to regex are also
    ; declared as options. I have not looked into it, but I
    ; assume this is due to the way Zend_Validate handles its
    ; own constructors.
    elements.username.options.validators.regex.options.pattern = "/^[a-z]/i"
    elements.username.options.validators.strlen.validator = "StringLength"
    elements.username.options.validators.strlen.options.min = "5"

Bringing it all together, the following is the first version of my login form.

    [login]
    ; General Form Information
    login.action = "login/submit"
    login.method = "post"
    login.id = "login"
 
    ; Form Decorators
    login.decorators.elements.decorator = "FormElements"
    login.decorators.table.decorator = "HtmlTag"
    login.decorators.table.options.tag = "table"
    login.decorators.form.decorator = "Form"
 
    ; Username Element
    login.elements.username.type = "text"
    login.elements.username.options.label = "Username:"
    login.elements.username.options.required = true
    login.elements.username.options.validators.alnum.validator = "alnum"
    login.elements.username.options.validators.regex.validator = "regex"
    login.elements.username.options.validators.regex.options.pattern = "/^[a-z]/i"
    login.elements.username.options.validators.strlen.validator = "StringLength"
    login.elements.username.options.validators.strlen.options.min = "5"
 
    ; Password Element
    login.elements.password.type = "password"
    login.elements.password.options.label = "Password:"
    login.elements.password.options.required = true
    login.elements.password.options.validators.strlen.validator = "StringLength"
    login.elements.password.options.validators.strlen.options.min = "6"
 
    ; Submit Form Element
    login.elements.submit.type = "submit"
    login.elements.submit.options.label = "Submit"
 
    login.elementDecorators.viewHelper = "ViewHelper"
    login.elementDecorators.errors = "Errors"
 
    login.elementDecorators.tableData.decorator.td = "HtmlTag"
    login.elementDecorators.tableData.options.tag = "td"
    login.elementDecorators.tableData.options.class = "test2"
 
    login.elementDecorators.label.decorator = "Label"
    login.elementDecorators.label.options.tag = "td"
 
    login.elementDecorators.tableRow.decorator.tr = "HtmlTag"
    login.elementDecorators.tableRow.options.tag = "tr"

This creates a login form with a username and password field along with a submit button. However, instead of being wrapped in a definition list using definition titles for labels and definition data for input fields, I have wrapped the labels and input fields within a table similar to the google login form. Notice though, that I have sectioned this form using [login]. Tthis is so that I can define all my necessary forms in one forms.ini file and load each form by section. I have also prepended each declaration with login. as a way to keep my form definitions organized and easy to read (to me at least).

Concluding this guide, I would like to reiterate, how useful I think Zend_Form is as it solves one of the most tedious process for any PHP project; form creation and validation. I hope it continues to evolve and mature, and I hope others find it as handy as I have. Although, if anyone has an easier solution, please let me know.

$loginForm = new Zend_Form(new Zend_Config_Ini('/path/to/form/config', 'login'));

This will create a Zend_Form object by passing it a Zend_Config_Ini object.

Unfortunately, when you decide to build a custom form using Zend_Config, the documentation on how this actually works, is extremely sparse. There are three examples of using the Zend_Config, however, they are not commented and there is no explanation as to how it works, there is only a weak reference to PHP object oriented code from which to draw conclusions from. Maybe, I am too used to the Java API documentation.

Anyways, after a few days with ZF, it has become apparent to me, that ZF is a very well written, powerful, extensible, and versatile PHP framework. However, due to its incomplete documentation, I would argue that its’ learning curve is fairly high, much higher than Code Igniter’s. In time though, I am sure the ZF developers will realize this, and make the effort to provide better documentation. In the meantime though, I am going to continue to use ZF and hopefully, take it upon myself to provide some insight; a Zend_Form tutorial using Zend_Config is already in the works.

Since I don’t play the game as much as I did when it first game out, I have no business trying to analyze the flaws of the original compared to what Blizzard has done and is doing with the sequel. Therefore, I will stick to enumerating the new additions found in this latest gameplay trailer.

Highlights

1. The Terran Command Center now doubles as an scv transport. This gives Terrans unprecedented mobility when trying to rebuild.
2. Terran buildings now have modular addons. Each addon, provides special functionality. In particular, the Reactor allows buildings such as barracks to double their output capacity.
3. The new detector, the Sensor Tower, upgrades into a radar tower which has a much larger range and allows players to detect enemies in the fog of war.
4. Battlecruisers (and possibly all major units) are upgraded individually. This means you must spend resources per Battlecruiser to give them your choice between the old Yammator Canon and the new Plasma array.
5. The Viking is the new Valkyrie. It deals area of effect (AOE) damage to capital airships, but thats not all. It can also transform into a ground assault unit.
6. The Banshee is the new Wraith. It is an air unit with the ability to cloak, but unlike the Wraith, it is armed with AOE missiles (This seems a bit too much considering the new Viking, so I wonder if it is only an Air to Ground attack unit).
7. As was seen in the original gameplay trailer, the Reaper is a new light ground unit with the ability to traverse terrain obstacles. However, this new trailer highlights the Reaper’s new armament: demolition charges. These demolition charges are basically land mines with timers.
8. The Terran Command Center now has the ability to transform into a planetary fortress, giving it a heavy artillery canon for defending against enemies.
9. The Thor is the new Terran heavy siege unit. It looks like a cross between a Battlecruiser and a Siege Tank as it has both, powerful laser canons and a siege mode.
10. Replacing the Vulture is the Cobra, a fast ground attack vehicle armed with a rail gun.
11. Last, but not least, are the Ghosts. However, Ghosts are no longer weak attack units. They come with a new “sniper” attack that is a slow and high damage (one shot against marines). In addition to the traditional nukes, Ghosts can call down drop pods which are basically paratroopers. This should make base raids and sieges particularly interesting.

Since this is the third time I have seen the gameplay trailer, I must admit, I am impressed with the direction of Starcraft 2. Although it stays true to the original in terms of gameplay, this sequel adds many new dynamics to the game. Each race we have seen so far looks like they will have many more options for building effective armies. Micromanagement will again most likely separate good players from great players, and as I said in my last post, terrain will probably be a big part of the game. All we need now, is the Zerg’s gameplay trailer so that we can marvel in what will be Starcraft 2.

Trailer Download

Blizzard’s Starcraft 2 movie page

The following is a code snippet from the HTTP and HTTPS documentation that shows how to easily send data using HTTP POST:

$postdata = http_build_query(
    array(
        'var1' => 'some content',
        'var2' => 'doh'
    )
);
 
$opts = array('http' =>
    array(
        'method'  => 'POST',
        'header'  => 'Content-type: application/x-www-form-urlencoded',
        'content' => $postdata
    )
);
 
$context  = stream_context_create($opts);
 
$result = file_get_contents('http://example.com/submit.php', false, $context);

Quick Explanation

1. http_build_query: Generates an URL-encoded string from an associative array. Example: array(’key1′ => ‘value1′, ‘key2′ => ‘value2′) becomes “key1=value1&key2=value2″

   This properly encodes the data for the post transaction.

2. stream_context_create: Creates and returns a resource to a stream context from an associative array of arrays in the format $arr[’wrapper’][’option’] = $value

   This creates a linear output stream to be sent during the request transmission.

3. file_get_contents: Acts exactly like file(); except that it reads an entire file into a string.

   This requests a file resource and puts the result into a string.

As always, I am still busy with my own job, family, and other personal projects, but I will make sure to update and enchance the plugin’s functionality regularly.

Feel free to visit the Command Center Homepage for more information and/or updates.

'before_widget' => '<li id="%1$s" class="widget %2$s">',

This has the nasty effect of creating widget wrappers according to their widget name due to the “%1$s”, which isn’t a deal until you actually have multiple instances of the same widget; in my case, the links widget. Having figured out the problem, I began searching for solutions online and stumbled upon the actual Wordpress bug report in trac. The proposed solution was to add the following line of code before the call to wp_list_bookmarks() in wp_widget_links():

$before_widget = preg_replace('/id="[^"]*"/','id="%id"', $before_widget);

Unfortunately, this solution wasn’t good enough for me because I didn’t want to have to remember this in case the next Wordpress release didn’t fix the bug. So, after some quick thinking I came up with the following bit of code that can be added to any theme’s function.php file (I think, I am a bit new to Wordpress widgets, in fact, this will be my first).

Edit: This code is actually the exact copy of the widget_links code that ships with wordpress in the widget.php file. All I did was add the previous fix and moved it into functions.php to create a custom widget.

function widget_my_links($args) {
    global $wp_db_version;
    extract($args, EXTR_SKIP);
    if ( $wp_db_version < 3582 ) {
        // This ONLY works with li/h2 sidebars.
        get_links_list();
    } else {
        $before_widget = preg_replace('/id="[^"]*"/','id="%id"', $before_widget);
        wp_list_bookmarks(array(
            'title_before' => $before_title, 'title_after' => $after_title,
            'category_before' => $before_widget, 'category_after' => $after_widget,
            'show_images' => true, 'class' => 'linkcat widget'
        ));
    }
}
 
if ( function_exists('register_sidebar_widget') )
    register_sidebar_widget(__('My Links'), 'widget_my_links');

This should add a custom widget called ‘My Links’ when you view the Presentation->Widgets menu. Replace your current Links Widget with this one, and you should be set to go. No more invalid markup, at least not from the links widget.

Web standards is a general term for the formal standards and other technical specifications that define and describe aspects of the World Wide Web. In recent years, the term has been more frequently associated with the trend of endorsing a set of standardized best practices for building web sites, and a philosophy of web design and development that includes those methods.

I have been a proponent of Web standards ever since I created my first web site back in early 2000. Back then, I was only following what I thought was the correct way to do things, and having the word ’standards’ seemed to make this movement official for me. As I learned more about these web standards, the importance of the best practices set forth along with the concept and goals of creating markup that would display the same across browsers, the more it all seemed to make sense.

However, seven years later, I am still creating web sites/applications using PHP, XHTML and CSS, but I am getting ever so frustrated with these so called “web standards,” mainly due to the quirks and lack of support in IE6 and to some degree IE7. I am not an XHTML or CSS guru, but I think I know enough to write decent markup and styles to be effective (please don’t judge me using this site, after all, this theme was found on a wordpress theme site and I haven’t had the time to clean it up). Just the other day, I was working on a site that required a three column layout, with columns of equal height, so I decided to use alistapart’s Holy Grail.

This worked great in Firefox, Safari, IE6/7 and even Opera, until I tried to accomplish my next task, adding a picture gallery created by floated elements. As most of you might have guessed, everything was fine except with IE6. Now why is it that I always have to find ways to hack my styles just to get them to work with IE6 or 7? Why can’t Microsoft finally create a decent browser. Well, on this day, I had had enough. I decided to scrap the Holy Grail layout and create my three columns using a table. Yes, thats right, I used a table layout to accomplish my three columns and it worked great. Not to mention I got it done without any hassles from any of the browsers I was testing with.

Before anyone begins the flaming, I will start by stating that I know this isn’t semantic. I also know that this use of tables is deemed inappropriate by the w3c whom states:

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

I merely decided to save myself the agony of debugging IE6/7 issues. I still support web standards, but I don’t see how it is completely feasible to follow them blindly when we all know well and good that the most prevalent browser used worldwide, just doesn’t fully support them. Until these set of best practices are adopted by all the major browsers, to their full extent, they will never be more than best practices, and even then the term will be somewhat misleading.

Maybe I have been a bit slow to come to this conclusion, after all, most things can be successfully conquered utilizing web standard, but I am not the first to point out its flaws. Of course these really aren’t flaws of the standards set forth, but rather one prominent browser that fails to adhere to them. As a young developer, and as a developer who plans to be in this field for a good portion of his working career, what can I do to further along the goals of standardizing XHTML/CSS best practices? What is the rest of the community doing? And how well is it going?

Sorry for the rambling, but I have a dream… A dream that one day, all browsers will be created equal and all developers will blissfully enjoy writing clean concise markup and all users will see the same beautiful interface into what we call the world wide web.