New plugins are:

• Album
• Band
• City
• Country
• ImageFile
• Location
• Podcast
• PodcastItem
• RssFeed
• RssFeedItem
• Song

I have decided to remove all documentation for the data plugins, except the class documentation. This reduces the amount of code for each plugin and makes it a lot easier to overview.

However, I have kept the documentation for classes that have methods/functions other than just the verify function, since this piece of documentation can be of use to developers, while properties and constructors are pretty obvious.

There are big differences with how file bundling is done now, compared to the first alpha and previous Wigbi versions:

• Pros:
  JS/CSS file bundling is Wigbi-independent and thus a new, full feature
  Compared to Wigbi 1.0 a1, no session handling is required
  JavaScript init code is packed and thus compact and obfuscated
• Con:
  Since no additional PHP file is used, the JavaScript init code is written to page

A new alpha release will be up shortly, once a bunch of data plugins have been created.

In Wigbi 1.0, this new approach will replace the bundling that is used in 0.99.2, where the bundle PHP file automatically appends all JavaScript files that exist in the wigbi/js folder.

The old approach works well, since you just add all files you want Wigbi to include into wigbi/css and wigbi/js. However, this new approach is much more flexible.

In Wigbi 1.0, Wigbi will handle files by itself, and instead create a valid path to the bundle URL, which it then adds to the page.

This means that bundle URL will be entirely independent of Wigbi. You can thus use it for js/css files that exist anywhere else within the application, and even without being bound to use Wigbi.

The bundle urls will be
~/wigbi/bundle/js:<comma-separated file/folder list>
~/wigbi/bundle/css:<comma-separated file/folder list>

For further information, check out the full post here.

   function callBack(object result, string exceptionMessage)

This means that whenever anything causes the async postback to crash, Wigbi will (try) to handle the error and return it as the second parameter in the callback method.

I have also rewritten all classes that returned an error string if some methods fail.

I will also connect my development environment to the Google Code SVN, so that all checkins will be instantly available. Hopefully, this will simplify the release handling as well.

Regardin UI plugins, I will start to convert all existing UI plugins to Wigbi 1.0. However, since Wigbi 1.0 will come bundles with jQuery UI (which can be removed if it is not needed), a couple of Wigbi 0.92 UI plugins will not be converted and therefore not available in Wigbi 1.0.

A couple of such plugins are PopupWindow and AutoCompleteExtender, for which there exists greeaaaaat jQuery UI alternatives.Wigbi will instead provide more functional UI plugins, like login/logout forms, file upload forms etc.

During development, however, I came to the decision that all functions that returns an error code/array when an operation fails should throw an exception instead (except the validate function, which returns any errors). The Wigbi AJAX handler should then always return a [result, error] result, which the Wigbi.ajax callback method will always receive as a parameter.

This makes it possible to implement a really clean solution, where server exceptions and AJAX errors are exposed in the same way. I will rewrite my code so that it behaves in this way, which will be the big difference between the alpha 1 and 2 releases.

The alpha package includes:

• The “wigbi” system folder, which should be in the root of every Wigbi application.
• An “index_wigbi.php” page, which outputs “Hello world” if Wigbi starts OK (original, huh?)
• A folder with the source code.
• A folder with the Wigbi 1.0a documentation.

The alpha package includes no plugins, since I have to rewrite them from scratch. They will be up as soon as they are finished, which is when they have full test coverage and are fully documented.

Feel free to download Wigbi and give it a try and please have patience with the fact that there are no wizards or demos available yet. If you let me know that you are waiting for them, I will work faster

Wigbi 1.0a can be downloaded here.

Since Wigbi 1.0 is developed with TDD, I have found several major bugs that I have not known about before. Thanks to the fact that I have unit tests for every bit of source code, future Wigbi versions should be rock-steady as well.

I will generate documentation for Wigbi 1.0a and will then put it out for download. Notice, however, that no the alpha release will include no plugins, since I have not ported the old versions to 1.0 yet.

All of you who prefer to download the source code will notice that I have removed a lot of in-code documentation, since I believe that the code speaks for itself. The class documentation has been slimmed down a bit as well.

Wigbi 1.0 alpha download will be out really soon…but now: bed.

The Wigbi 1.0 release is way different than the 0.99.2 version that was released earlier this year. It is a complete rewrite and features a lot of improvements.

The beta will be out at the end of July, but will not contain any plugins, since all 0.99.2 plugins have to be modified to work with Wigbi 1.0. It wouldn’t take long though.

In this post, ~/ indicates the application root, which is where the wigbi folder is located.

In PHP, the CacheHandler class uses page relative paths to the cache folder. All class functions are executed directly when called, which makes page relative paths natural.

In JavaScript, however, the same does not apply. Since the JS class uses asynchronous methods, a page that calls a method will not exist in the same folder as the one that executes it.

This leaves us with an interesting scenario. Say that the page ~/admin/account/myAccount.php sets the cache folder to ../cache.

With PHP the cached files will end up in ~/admin/cache/.

With JavaScript, however, the call is sent to ~/wigbi/pages/postBack.php, where it is executed. Thus, the ../cache path will make the cached cached files end up in ~/wigbi/cache/.

Using the same kind of paths for PHP and JavaScript will therefore not work. Instead, the JavaScript class is set to use application relative paths. Instead of ../cache, use admin/cache.

The CacheHandler JavaScript class will automatically adjust application relative paths so that the postback page can use them.