No ideas here

Although Xcode is the only real world 64-bit application on Leopard, it is not yet fully dedicated to support the 64-bit applications on 100%. It has still major defects using debugger at 64-bit applications. I tried to make one my application 64-bit, but the debugger stopped me from doing it so, and I switched back to 32-bits during the development. However, I plan to get back to 64-bits later, I’m not giving up though… [-;

This is how debugging should look like

At first, I started wandering where did my objective-c variables go. I thought I hadn’t have switched on some build variable, so I was looking for some magic check box, but without any luck. After some searching, and experimenting, I found that when the application was running at 32-bit mode, everything was just fine, but when I switched back to 64-bit mode, all the variables went away. At the same time, I also found that gdb doesn’t allow me to execute any objective-c methods. This might be the reason why no variables were shown. This also sucks, since I call obj-c variables quite often as I need to display value of some object, or test something.

And this is how it is in 64-bits.

I don’t know what is the cause of this. It is apparently some change in the obj-c runtime system that broke the things. I don’t even know whether this worked at previous Xcode version (I used 3.1 now), so it might be just a bug, but quite annoying.

Leopard is a good start on the 64-bits way, but Apple has still long way to go if they want us to use and develop 64-bits as the main job. I hope that Snow Leopard will continue the current effort in computing to bring the real 64-bit environment.

I want to put here a short note that I put the JavaScript forms validator at Google code. I decided to keep the project’s home page here, although I’m thinking about moving it over there as well… The rest like source control, and the bug reporter will be at the google code. I will work on the code some more later this week since I found some deficiencies. No bugs, but situations that can’t be handled like for example when the description is inside the edit control. And for sure, there will be some more…

Yesterday I found that one my application doesn’t release NSWindowController. The problem was that I was not using NSDocument architecture, and releasing NSWindowController is a little different without NSDocument than with NSDocument.

By default, when closing a window with the red button on the top, you will not release the window controller object. If you want to do so, you must implement the windowWillClose notification in your window controller, and autorelease self. Yes, autorelease self, because this will release window controller later after the code that handles the click on the red button handles to the close event, and hides the window. During all this work, the window controller must be ready to react. Later, when your window controller gets disposed, it also automatically decreases retain count in the window, and thus the window object will be released as well. So you should use code such as this in your NSWindowController subclass:

@implementation MyWindowController
-(void) windowWillClose:(NSNotification *)notification
{
   [self autorelease];
}

Also don’t forget that your window cannot have two properties that automatically release some objects. Both must be set to FALSE. The first property releases the document on close of window (your application would crash if set to TRUE - there is not document - hm, Apple might check this as well, and not to crash the application). The second property is that the window itself will be released on close (your application would also crash since the window will release itself, and your controller will do the same later, so the release count will be 0 at the time of the second release). This second property is often set in Interface Builder application. So, consider calling these two functions when creating a new window.

[[myWinController window] setReleasedWhenClosed:FALSE];
[myWinController setShouldCloseDocument:FALSE];

HTML forms validation is always a pain. You must process the validation both server and client-side. The server-side part is obviously a problem of your server framework, but the client side is a problem that must be solved by JavaScript. I always used some custom scripts, for every project the same thing that was rewritten every time. Almost same code was used in different projects. So I told myself that I should do something about it, and decided to write a small JavaScript library to support client side forms validation. My goal was to have a JavaScript framework that will allow me to check the form with minimal use of coding. I wanted something like configuration driven validation. Another goal was to provide a consistent error reporting, so the user is always informed in a standard way, and the user will always know what is the problem. The error reporting also consists of translatable error messages. Yet another goal was to provide a consistent set of validation rules that can be applied on a wide range of the controls, and further extended.

Defining the validation

To define validation, I decided to use css classes to set the constraints. That means that you don’t need to call any code at all, but just include some javascript files, add some css classes to html tags, and the library will take care about it itself. Of course, you would be able to call all the things by coding, but this was not the point. The full automation is the biggest deal here.

Validation rules are defined as css classes. So some general information about its structure: validation rules always start with “val_”. For example rule for required field is “val_required”, so you will write:

<input type="text" class="val_required your_class">

Some rules can have parameters. These parameters are passed to the rule code automatically. For example if you want to define a rule for minimal length of 2 letters, you will use this code:

<input type="text" class="val_minlen-2">

Some rules can be applied to multiple types of components, but most not. The work on my todo list is an automatic checking of the validity of the control type.

Validation rules

There are included several validation rules that match the most of the needs. Of course, you can always add your own validation rules.The list of rules follows.

• required - presence of text or presence of
• minlen - minimal length of text or minimal number of selected items in select html element
• maxlen - maximal length of text or maximal number of selected items in select html element
• minvalue - minimal value
• maxvalue - maximal value
• int - value must be a number
• float - value must be a floating point number
• email - valid email address

Reporting errors

Error reporting is the final step towards the user. Displaying an alert is not enough anymore. Much more convenient towards the user would be to add the error message behind (on the right side of) the form field, and remove the error when it is not necessary.

The error is reported with the name of the field that is taken from the associated label. If no label can be found, the generic error text is used.

As it was said, it is possible to use localisation. Currently, the only supported localisation are generic English (so one for England, Australia, South Africa, and the US) and Czech. This part obviously needs a lot of attention in the future. If you want to change the localisation, you must explicitly state it as a class in your form. The class name is “val_lang-cz”.

Simple usage

So now it is a time to show some simple usage of the validation. Just a simple usage follows. Its purpose is to illustrate how to use it. The following input text has to contain at least 3 and at most 10 characters.

<input type=”text” name=”username” class=”val_required val_minlen-3 val_maxlen-10″ />

Future directions

The future directions would be to make sure that the validation works in any browser. Further adding more validators, adding an immediate error reporting after the control looses the focus, some more work at internationalisation is also needed. Further some more work at checking various types of controls is needed. Documentation needs to be updated, but to be honest, there is never enough documentation. Maybe I will add some more advanced AJAX validation of more complex situation that need communication with the server.

So that’s all. Hope you will enjoy it. I promise, since I will use it from today, I will update the code regularly, patch bugs, and release new features. This version is just a preview of what it might contain, so comments here, bugs to martin at kronos-software.eu.

DOWNLOAD

Documentation