New JavaScript / CSS file bundling implemented

The css/js bundling that I wrote about in my previous post, have now been fully implemented, and is verified to work.

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.

JavaScript and CSS file bundling in Wigbi 1.0

I have just blogged about JavaScript/CSS file bundling here.

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.

Wigbi 1.0 system and core packages almost done

I have almost completed rewriting all the Wigbi 0.99.3 system and core package classes. The new Wigbi version is fully test-driven, which is a huge improvement from earlier versions. All in all, the new version features a lot of improvements, some class/method removals and a much more slick framework.

All system and core classes are now entirelly independent of the Wigbi class. Only one static class remains (SessionHandler) – the rest have been made unstatic, with default instances that can be accessed via the Wigbi class.

I only have the Wigbi and WigbiDataPlugin (previously called Seed) classes left before I start to convert all the various plugins. All in all, the plugins should be a rather short business to convert, since they all benefit from functionality in already tested base classes.

The documentation will be slicker than before as well. I am currently considering to NOT write demos for all the various system classes and plugins, since the web site has few visitors. Instead, I think I’ll make it possible to request demos to be written, so that I only have to write demos when people need them.

Finally, the AJAX pipeline previously only supported functions that used base type parameters, like strings, integers, booleans and arrays. In Wigbi 1.0, I want to make it possible to serialize/unserialize data back and forth between PHP and JavaScript, and would thus need a serialize/unserialize implementation in JavaScript. Please let me know about any such implementations that gets the job done.

The work with Wigbi 1.0 proceeds

I am currently working with the Wigbi 1.0 release, which I wrote about earlier. I have now finished writing new versions for the following classes:

• CacheHandler
• IniReader
• JavaScript
• LogHandler
• SessionHandler
• Wigbi (part done)

Working with SimpleTest has simplified development a lot, which is why the pace is so good

In Wigbi 1.0, all system classes will be independent of the Wigbi class (except—the Wigbi class), which means that you will be able to use them for other purposes as well, without having to rely on Wigbi. The only static classes (so far) are JavaScript and Wigbi. All other system classes now have default handlers that are initialized by Wigbi and accessed as properties of the Wigbi class.

Several classes remain,  as well as data and UI plugin classes…but I’m getting there.

Wigbi 0.99.1 – Obfuscation optional

I have just implemented a new feature, which will be available in Wigbi 0.99.1.

First of all, all future releases will contain unobfuscated source code, that can be used instead of the obfuscated source code files that are used by default. This will make it a LOT easier to find and fix any bugs that may exist in the source code – just replace the obfuscated source code files with the unobfuscated ones and you will get error reports that make a lot more sence

This will also make it a loooot easier to add your own custom code into the Wigbi source code. The source code download features the source code, sure, but until now, it has been hard to add custom code into the Wigbi framework source code. Not anymore.

Furthermore, Wigbi 0.99.1 will make it possible to disable obfuscation of the JavaScript source code files that are generated by the Wigbi Runtime Build engine, which will make it a lot easier to find and correct bugs in the JavaScript source code for seeds and controls that are added to a Wigbi application.

Wigbi 0.99.1 will be available when all demos are completed.