The earlier version of the SDK surprisingly provided alot of functionality and stability for such an early release. Because of this I am very excited and hopeful for this beta release.From what I quickly read today it seems that the beta is bringing some new features while stripping some of the old features as such as the built in GTalkService and the Bluetooth API. One new feature that is really appealing to me is the graphical preview for XML layouts when using eclipse. I can really see myself getting alot of use out of this because before it was kind of a pain to test out your layouts quickly as you changed and modified things.

So if you want to find out more about this beta, you can read more about this here. In a couple of days when i get this final project wrapped up for school (yes i still have one left to do) I will be downloading and installing this beta and working with the rest of the bot-talk team to bring it up to speed. When this happens I will post some more information on our findings.

Anyways, I’m getting a bit off topic, so expect more blogging, and a lot more source from me soon as I will be trying to keep busy with this time off that I now have.

First to organize the controls into a group I wrapped them all in a panel control. This allows me to grab all of the controls from the panel and loop through them like so. While looping through them I apply a new event to the click event property and specify my own custom event handler which is defined later in the class. This all occurs in the constructor of the form.

public Grid()
{
	InitializeComponent();

	foreach (Control c in GridPanel.Controls)
	{
		c.Click += new System.EventHandler(this.ClickEventHandler);
	}
}

Now I define the handler which I stated above as the click event handler to handle all events from any controls in the panel. Of course since one handler is being used for all controls we need some way to determine which control was clicked. I do this by grabbing the control reference from the sender parameter, and grabbing the ID of it.

private void ClickEventHandler(object sender, System.EventArgs e)
{
	if (GridClicked != null)
	{
		PictureBox p = (PictureBox)sender;
		mId = p.Name;

		//do something here
	}
}

Hope this helps simplify your code in the future by reducing repetitive events for similar controls.

Todays post will be focused on setting up apache mod rewrite rule to control your url structure and to allow a clean way of routing requests to your controllers.

Apache mod re-write
Apache mod re-write can be used for a variety of things. For further reading on the subject I recommend visiting the Apache documentation. What I am about to demonstrate will give you the functionality to turn ugly urls like “http://yourdomain.com/index.php?module=mymodule&action=myaction” into a cleaner and more search engine friendly “http://yourdomain.com/mymodule/myaction”. In the next post I will describe how to parse these urls and dispatch the appropriate php scripts.

The first thing you need to do is create a .htaccess file in your web root directory.
% touch .htaccess

Enter the following code into this file.

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)$ index.php?module=$1 [L,QSA]

What this does is start the rewrite engine and gives it a rule for interpreting urls that follow the regex expression specified. The $1 can be thought of as a variable in which the parameters are substituted. ^(.*)$ tells apache to take any series of characters and substitute it where the $1 is.

This is not by any means the only way to do this and there are more restrictive ways then mine. I however like to keep mine more open because I explode the url and parse it as I need to. Doing it like this removes issues regarding whether the url contains a closing slash or not, or how many parameters are supplied. These details are handled in the dispatcher.

For another implementation of this rule visit my friend Greg Meloche’s blog at GeekHut.org.

My next post will cover the router/dispatcher, where you will see how this url is parsed and where the real functionality takes place.

Here’s the basic instructions to do so in Fedora 8 using Firefox for all of you who are interested in doing this…

Login as root.
% su

Find your plugins directory for firefox and change to that directory. Mine is in my home directory
% cd /home/craig/firefox/plugins

Create a symlink to the java plugin, assuming you know where this is. Refer to mine if you are unable to locate yours.
% ln -s /usr/java/jdk1.6.0_06/jre/plugin/i386/ns7/libjavaplugin_oji.so

Heres a trick you also may not know. By typing the following in the Firefox address bar you are presented with plugin information.
about:plugins

What I am going to try to demonstrate in this post is three things; signing an assembly, moving an assembly to a different location on the system, and forcing the client to use a different version of the assembly. I will break this up into different steps.

Signing an Assembly
To sign an assembly we need a public and private key pair. This can be done on the Visual Studio command line using the following command.

% sn -k mykeyfile.snk

Next we need to associate our assembly with our key. This can easily be done in Visual Studio by going to the project properties for the assembly and going to the Signing tab. Here you can browse for your key and attach it.

Moving the Assembly
To move the dll to a different directory other then the same folder as your client exe file we need to add a config file to the client folder. It should be the same name as your client.exe and should have the .config extension. Edit this file with an editor of some sort, I prefer Notepad++ in Windows.

Enter the following:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Classes" publicKeyToken="5ce03d2c8ba6d217"/>
<codeBase version="1.0.0.1" href="C:/Classes.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

For now I won’t explain all of this file, but will focus on the task we are doing. The parts which are important to us are…

<assemblyIdentity name="Classes" publicKeyToken="5ce03d2c8ba6d217"/>
<codeBase version="1.0.0.1" href="C:/Classes.dll"/>

The assemblyIdentity specifiys the assembly name and public key token.
To get the public key token to enter here you can use the command line tool sn again with the -T flag.

% sn -T the_dll_name.dll

The codeBase allows us to specify an alternate location of the assembly, in this case the C:\ drive. You can change the location to whatever you want. Remove the dll from the client folder and to the new location, run the executable and you should still be able to use the assembly just as before.

Binding to New Versions
To force a client to use a specific version of an assembly we can add the bindingRedirect tag.

<bindingRedirect oldVersion="1.0.0.0" newVersion="1.0.0.1"/>

Specify the two attributes, the old version and new version. The new version being the version you currently want to use. Again, save and run the executable and if all has gone well you should only be able to use the assembly with the new version.

In case you are wondering, you can change your assembly version in Visual Studio by going to project properties->Application tag->Assembly Information button.

Hope this helps in your assembly configuration tasks.

The main components consist of the following.

The Dispatcher:
The dispatcher is the main controller, front controller, or router as I’ve also heard people call it. It handles extracting the path data from the URL and decides which module and action to run. It is the boss of the application and is in charge of initialization, authentication, and calling the event on each module.

Module
I call this somewhat of a mvc hybrid because I don’t directly consider the module a controller. In a way it is a secondary controller to the dispatcher but I find it performs more then just routing data between the models and view. To think of it in file structure terms, the module specifies a folder on the system, and each class/php file in that folder represents a major component of that module. Within each of these classes there are methods(events) that can be called which act on these components. For example a users module may have a profile being the class and the event being edit. We could then call this with http://test.com/users/profile/edit/

Model
In a way we could stick most of the database interaction and model code within the module if we really want to. This however would create really bloated module classes and limit code reuse. I find it better to keep my models separate and treat them as data object classes who’s main focus is to encapsulate data and directly talk to the database.

Presenter
The presenter is the go between for the module and the view. Essentially it includes the view template and takes the data from the module and generates variables which can then be used by the view template to display its content. By doing this we can abstract the presenter later and easily change the final output to say a smarty template or some other format.

View
As mentioned above the view gets its data from the presenter. It contains very little php code with its only purpose being filling itself with the data it receives from the presenter and generating the final output document.

Authentication
Authentication occurs in the dispatcher before running an event of a module and is implemented on the component level. As mentioned above each module is made up a series of pieces (components) which make up its general functionality. Each of these components derive from a module authentication class. This gives each component the same interface for authentication to be performed by the dispatcher. At this stage I have created two parent module authentication classes that can be inherited from; private_module and public_module. Private module is a module that checks for session state to ensure a user is logged in. The public module authentication just returns true because it requires no authentication for the user to use the module. I chose to do it this way for flexibility because new authentication types can be easily added to the existing framework and integrated with little modification to anything else. Any other globally required module functionality can also be added to these classes and forced upon all components if need be.

So that is the general break down of my framework at this stage. Feel free to add any feedback and suggestions.

I decided to give lftp a try and so far I am really liking it compared to regular ftp and it was able to do what I hoped.

Uploading an entire directory with lftp can be done with the mirror command and the -R option as seen below.
% mirror -R some_directory

To download an entire directory from the server just exclude the -R command.
% mirror some_directory

Feel free to let me know if there is a way with regular ftp to do this. I didn’t spend a whole lot of time researching it but from what I found it didn’t seem possible.