Since we started development on DiLoc 2.0 we wanted to refactor some parts of our database-propel layer and ExtJS integration. For this to work we needed some additional custom fields in schema.xml (because we generate ExtJS Frontend Models automatically from schema.xml). Putting even more stuff (like validations which we wanted to define only once in schema.xml in our updated framework) into into our schema_addon.xml felt more and more wrong. As I heard of ORM Designer before, it was time to evaluate if ORM Designer could replace MySQL Workbench in our workflow.

On our first try I was quite underwhelmed because ORM Designer did not support Propel-validations, the prime feature we wanted to use it for. I asked the developers of ORM Designer if support for validations could be added, and provided some links for documentation about how validations work with Propel. – Lo and behold, on the same day a new beta version of ORM Designer was made available for us. – Even including a lengthy blog-post explaining the new features. I tried it out and it worked perfectly. Since ORM Designer is very extensible, we even got a config file extending tables and columns with new attributes we needed to generate frontend-models from schema.xml. I was very happy and tried adding behaviors to our tables, only to find out that behaviors where only supported for Doctrine in ORM Designer. – But no Problem, after some emails back and forth between me and the developers, we got a shiny new version supporting all Propel 1.6 behaviors, even with all available parameters and so on! – Great! During this, the developers where extremely friendly and  interested in implementing the things we needed. They also provided us extended testing-licenses so we could test ORM Designer some more.

So now we can design our database schema with ORM Designer and can directly add all needed fields and attributes to our tables, columns, etc. and directly export to a fully Propel 1.6 compatible schema.xml. We dumped our handwritten schema-patcher and even added an additional attribute to all columns that we needed.

ORM Designer with validators and our custom fields.

ORM Designer lets us even enhance schema.xml in the future should the need arise. We feel confident in having found the right tool for our needs. The only missing point when coming from MySQL Workbench, is that you cannot have multiple “diagrams” that showed your tables. This allows you to add custom diagrams for parts of your schema, where you only need some tables. This allows you to break your schema in parts and print out nice overviews on parts of the schema only. ORM Designer allows you to group tables into regions, but all relations to related tables are always shown, even if they go outside a region. In this regard Workbench is more flexible, even providing different relation-notation styles, etc. So ORM Designer is really really great on directly working with the ORM of your choice (Propel, Doctrine, Doctrine2,CakePHP, Symfony), and is really customizable for importing, exporting, and adding custom fields. This is really cool. But on the side of visualizing your schema, Workbench has still the edge over ORM Designer. Here is hope that the developers of ORM Desinger catch up in this area.

We urge you to try out the current Beta-Release (which is extremely stable) of ORM Designer! It has really great Propel 1.6 support, including all Propel-table and column-attributes, behaviors, validations, etc. And even if some feature you need is missing, chances are high that they are able/willing to implement it for you. This is in high contrast to MySQL Workbench where custom development would be unthinkable I believe.

Since the release of ExtJS 3.0 many developers are waiting for an Adobe Air based application that includes the excellent ExtJS API Documentation for easy offline use. Now you do not have to wait any longer! Just use ExtDocSuite, the all-inclusive documentation suite for ExtJS. Compared to the outdated ExtJS 2.3 Documentation for Offline use, this has some extra tricks up its sleeve:

• Includes the latest Documentation for ExtJS 3.1.1
• Also includes the latest ux Documentation from the examples/ folder
• Also includes the latest Ext.Air Documentation.
• Search works (for me it did not work in the official App from the Ext-Team)
• Integrated Update-System so that your documentation always stays up to date

Disclaimer: This is based off the great documentation provided by Ext. This App would not be possible without it. We did not write the documentation, we merely packaged it as an Air Application and added some tweaks here and there. So all the kudos goes to the Ext Team for providing such a great documentation Tool. Thanks alot!

To Install ExtDocSuite, just head over to the download-page and click on the shiny install button.

If you have questions or suggestions, comment below or on the download page.

Lets see what is new:

• Works with Workbench 5.1 (OSS and SE)
• Adds support for Workbenchs User Data Types
• Fixes BOOLEANS appearing as UNKNOWN (when using Workbench 5.1)
• Supports Propel 1.3 defaultExpr-Attribute
• Add name-attribute to unique and index-tags
• Add size-attribute to unique-indexes and normal indexes only if size is available

This means that it works now with the actual Workbench-Release and fully supports Propel 1.2 and Propel 1.3. It should also work with the upcoming Propel 1.4 but 1.4-specific features such as behaviours are not yet supported.

Download Link: MySQL Workbench Propel-Export Plugin v0.5
(Be sure to reload the file if it still shows the 0.4 version)

If you have questions regarding the new features or you find bugs / have suggestions, don’t hesitate to leave a comment!

Edit: Fixed link. Sorry!

This is what is new:

• Added support to set database baseClass manually
• Added support to set phpName per table manually
• DATETIME type is converted to TIMESTAMP type
• Added support for onDelete and onUpdate foreign key constraints (based on work by Antoine Noal aka Hvannentir)
• size and scale support for DECIMAL columns (based on work by Antoine Noal aka Hvannentir)
• support for multiple foreign key references (thanks for pointing that out Antoine!)

The first to features where added because I want to have other PHP-names than what propel generates automatically (Table named customers but class name should be Customer). I also have a custom baseClass injected in the inheritance tree to be able implement generic features for all my objects, so I needed the baseClass attribute. – Not beeing able to set this from the workbench export meant that I had to patch the generated schema file on every update with a small script which corrected the issues. With the new features I can now omit that extra step.
To use the baseClass-functionality, just use the new menu-entry “PropelExport: Set custom baseClass” inside Plugins -> Catalog.
To use the phpName-functionality, simply right-click on a table and use “PropelExport: Set custom phpName”.
Important to note: If you want to remove a previously set baseClass or phpName, enter one empty space as name. (I had to do this because of a shortcoming of MySQL Workbench, which does not enable me to differentiate between an entered empty string or a press on cancel).
The entered names are also saved in the Workbench file, so subsequent exports will automatically contain them. If you want to see the entered values, just run the corresponding menu-entry. The currently set text is displayed in paranthesis only in the title-bar of the dialog. (Another shortcoming in the used Workbench:input method.) Simply press cancel to keep the original text.

The DATETIME issue was fixed by me long ago, but I forgot to post the new version, so 0.4 also contains this fix.

The other features are mostly based on the work of Antoine Noal, although I did some small improvements/corrections. Thanks again for your work, Antoine!

Download Link: MySQL Workbench Propel-Export Plugin v0.4
(Be sure to reload the file if it still shows the 0.3 version)

If you have questions regarding the new features or you find bugs / have suggestions, don’t hesitate to leave a comment!

Luckily, my mind reminded me of something I stumbled upon some months earlier. It was labeled “Try this out when you have time” in my mind. – Stupid me, only wanting to try this out if I have time! So I decided the time is right to try out FirePHP now. – And boy is this useful and easy to use! After some weeks of using, I can not imagine working without FirePHP anymore. So let me show you what this is all about.

FirePHP lets you debug your server-side PHP-code right inside Firebug! This is a very smart idea, and it works great. For this to work, you need two things: First, the FirePHP Firefox extension which plugs into Firebug and extends it. Second: the small PHP library to use on the server-side to output messages right into Firebug, without interfering with your normal XML or JSON output.
FirePHP does this by sending the data inside the response-headers of the response. This way, they do not modify the data that you intend to send with your request. The FirePHP Firefox extension then takes care of parsing the additional response-headers and output them inside Firebug. Neat!

Here are some screenshots showing you how this works:

Besides the things I showed in the screenshots you may also output arrays and messages with different styles (warning, error, info) etc.
If you use the current development-version of the firefox plugin (version 0.1.0.1) and a current svn-version of the php library, you can even output stacktraces into firebug:

For more examples head over to the FirePHP webseite which offers a very good documentation on how to use FirePHP. The developer even provides libraries to integrate FirePHP with the Zend Framwork, Symfony, and Aptanas Jaxer. I think it wont be long until someone writes some serverside code for Ruby or .Net which would make it possible to use FirePHP with other languages.

So in essence, what I wanted to say is: Try out FirePHP, its a really nice addition to Firebug, easy to use, and makes it a pleasure to debug server-side code!

You have an Ext form into which you loaded data through the load() method. Later on you want to clear the form because you want to reuse it for a new empty record. In this case the forms reset() method will not work like you want, because it will reset the forms values to the last loaded values from load().

But if you go through all fields and use setValue() with an empty string, the isDirty() method always returns true because the fields where modified manually.

However, the solution is easy: Load an empty record into the form. This lets reset() work afterwarts correctly, and also lets isDirty() work like it should. The tricky part is, automatically creating an empty record which contains all fields the form expects.

Here is a simple plugin which you may drop into a FormPanel or BasicForm:

/**
 * This plugin can be either used on BasicForm or FormPanel.
 * In both cases it adds a method clear() to the object
 * which allows to clear (empty) all the forms values.
 * This is opposed to the reset() method which resets all values
 * to the last values loaded through a call to load().
 * But sometimes (e.g. when you want to recycle an existing form for use
 * for a new record, you have to clear the form and also corectly reset
 * the isDirty() flag.
 *
 *
 */
Ext.ux.FormClear=function()
{
 
	this.init=function(_object)
	{
		if (typeof _object.form=="object")
		{ //we are a formpanel and have a form, be kind and also add the method to the basic form
 
			//clear method for the underlying form:
			_object.form.clear=function()
			{
				var data={};
				this.items.each(function(item)
				{
					data[item.getName()]=null;
				});
 
				var emptyRecord=new Ext.data.Record(data);
				this.loadRecord(emptyRecord);
			};
 
			//clear method for the forpanel itself
			_object.clear=function()
			{
				var data={};
				this.items.each(function(item)
				{
					data[item.getName()]=null;
				});
 
				var emptyRecord=new Ext.data.Record(data);
				this.form.loadRecord(emptyRecord);
			};
 
		}
		else
		{ //we are a basicform
			_object.clear=function()
			{
				var data={};
				this.items.each(function(item)
				{
					data[item.getName()]=null;
				});
 
				var emptyRecord=new Ext.data.Record(data);
				this.loadRecord(emptyRecord);
			};
		}
	};
 
};

It enhances both FormPanel or BasicForm with a clear() method which clears all form fields and resets the form to a new empty form.

To use it simply add the following line to a FormPanel or BasicForm config-object:

plugins:[new Ext.ux.FormClear()]

That will then automatically add the clear() method to the FormPanel/BasicForm.

I hope some of you find it useful, because I know some of you already stumbled upon this issue.

Now I have a much improved solution: A plugin for MySQL Workbench that allows you to export your current catalog as Propel schema file.

Like the XSL I wrote, it supports the same features:

• Columns with:
  • Default values
  • Auto-increment attribute
  • Size
  • Description
  • Required-attribute
  • Primary-key attribute
• normal extra keys
• unique keys
• foreign keys

Currently it creates propel 1.2 compatible files, but I plan to publish an update once propel 1.3 is available as rc.

The plugin allows you to export the propel-schema to the clipboard so that you can paste it everywhere you want, or you may export it to a file. Unfortunatly MySQL Workbench does not yet have a way for plugins to show a “file save as”-dialog, so you have to type the path in manually. I hope the MySQL guys implement a file selector in the next version, as it should be doable quite easily. If that becomes available, I will update the plugin accordingly.

The neat thing is, that the export path is saved inside the Workbench file, so on subsequent exports you have the possibility to overwrite the last file right away without entering a path again.

The plugin certainly contains bugs and shortcomings, but I think it is a good start. If you have a case where the plugin does not export your file correctly, please send me the workbench file and explain what gets exported wrong, and I will hopefully be able to provide a fix for it.

And if you are a lua-monkey then dont hesitate to point me to ways to improve the code of the plugin. This is was my first time experience with lua and as such it may very well be not perfect.

So, without further ado, here is the MySQL Workbench Propel-Export Plugin v0.3.

How to Install:

Copy the file to your modules-folder inside the Workbench installation. This should work in all versions of Windows prior to Vista.
On Vista this may not work due to the automatic directory-redirection. In that case place the file into that folder: C:\Users\<username>\AppData\Roaming\MySQL\Workbench\modules\ and it should work perfectly.

After you placed the file into the directory, simple restart MySQL Workbench and the plugin should show up in the Plugins -> Catalog menu. The two entries from the plugin are prefixed with “PropelExport:” so you should be able to find them easily.

Thats it! Now go ahaed and test the plugin, and report how it works through the comments section! Thanks!

This review is in no way intended to be complete, and should provide just an overview or first look.

For the purpose of this review I created a small database schema for a project management software. The database design currently supports the following features:

• Multiple customers
• Unlimited projects per customer
• Unlimited users per customer
• Users may take part in projects and have customer-defined roles
• Projects consist of unlimited milestones
• Milestones consist of unlimited tasks
• Tasks may have dependencies on other tasks
• Users may take part in tasks

You see, its fairly basic but consists of enough tables to show off the features of MySQL Workbench.

Creating the schema

Adding the needed tables for the schema was easy and straight forward. MySQL Workbench allows you to add/move/edit columns at will, and you may specify format, keys and other column-related properties. A nice feature is, that it allows you to add comments on a per column-basis so you are free to document/explain difficult columns as you see fit.

Editing Foreign keys is very easy as you can see in the next screenshot. Selecting the referenced table and referenced column works with drop-down boxes so you automaticaly get all posibilites, and it is not possible to get typos. This is very easy and comfortable. You may also set options for the foreign key (OnUpdate/OnDelete) and comment the foreign key.

Adding Indexes is achieved by double-clicking a column when editing columns (for easy primary keys). If you want special or additional indexes, this may be done through the indexes tab of the table:

During development it is useful to insert testing data into the tables. For example a set of predifined users. This is possible through the inserts-tab. After a click on the “Open Editor…”-button you get a nice editor which allows you to fill out some rows for the table:

Unfortunatly the editor has some shortcomings: It does not allow you to resize the columns, and auto-incremented columns always get 0 as value, which might be confusing for novice users.
The generated INSERT INTO clauses are then displayed and may be copied to clipboard or automatically inserted into the table when creating the database. (See below)

I think this covers the most needed features concerning table creation and editing. If you still want to define advanced parameters like triggers, table-partitioning, advanced options, etc, you are free to do so, all possibilities are there.

Documenting the schema

When you finished with your schema, you probably want to document it. The most common way to this is through an EER Diagram. MySQL Workbench allows you to add multiple EER Diagrams for one schema. You may arrange the tables on it youself, or let Workbench do the dirty job through the option “Create Diagram for Catalog Objects”. For my example database it gives the following diagram:

As you can see the automatically generated diagram is not quite optimal as several lines overlap tables and so on, but for a start its not bad. You are free to move the tables around and group them in logical parts.

Unfortunatly while editing the model and moving the tables around, MySQL Workbench crashed. I reported the Bug on the Bugtracker, lets see if they may fix it.

After messing around with it a little bit, I came up with this:

If you dont like the Crows Foot notation, you are free to choose one of the available notations. (Crows Foot, Classic, Connect to Columns, UML, IDEF1X). Personally, i like “Connect to Columns” best, because it makes the foreign key relations more clear:

Sadly, when using this notation, the lines are always a direct connection without edges. I imagine this gets really messy with big databases and many tables. This should be improved further.

As you may have seen on the screenshot, the diagram view also allows to create relationships directly in a graphical manner which may be easier for some. – I prefer to define foreign-key relationships in the table-editor. When you add a new foreign-key relation, it immediatly shows up in the diagram. -No need to refresh or anything. Another possibility is to add text-notes, images and layers to the diagram to break things into parts or explain it better. I find this quite handy, allthough you apparently cannot change font-sizes of text-fields. That would be useful for headings, etc.

When you are satisfied with your diagram you may export it into PNG, SVG , PDF or Postscript file.
Exporting to PNG worked flawlessly, exporting to SVG showed many strange lines goeing trough the tables, but that could also be firefox’ fault. I did not investigate that further.
Exporting to PDF also worked great, and has the advantage that it is vector-based, so is easily zoomed and printed in high resolution.

Another way to document your schema is to generate a HTML-Report of it. There are some templates to choose available, this is the basic-frames template:

Allthough nice, this particular template is buggy. When clicking on a table on the left, it will not scroll to the table on the right. – But that should be easy fixable.

Connecting to a database

So what do you do when you created your schema, documented it, and gave it to your boss? – You eventually begin working on the software which uses the schema and want to have a real database based on that schema.

MySQL Workbench allows you to “Forward-Engineer” the schema into a database. First you should validate your schema using “Model -> Validate”. You may also do this during the Forward-Engineer Wizard, if you want.
This shows you common errors like missing indexes, etc. This is a really nice feature, but the output lacks in several ways. The most obvious problem is that you cannot distinguish the found problems from the normal log entries:

When trying to fix the errors one error was not fixable as I was not able to set a correct default value for a boolean column, I tried 0 and false, both lead to an error. The other error just said “Referenced column name is invalid for foreign key customer”. That was not really helpful as i named all foreign key relations to the customer table “customer” so I did not know which table was meant.

When using the Forward-Engineer Wizard there are some options presented (Add inserts, generate drop statements, etc), after validating the schema, the SQL to create the database is generated. You can then copy it and do with it what you like, or continue the wizard and connect to a database and execute the statements directly. However this did not work with my schema as I got the dreaded 121-error:

Error 1005: Can’t create table ‘.\myproject\projects.frm’ (errno: 121)

This happened for all tables with foreign key constraints, and that allthough foreign key checks are disabled while creating the tables through this statement:

SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;

I already reported some forward engineer wizard related bugs in the past, but apparently there are still some left. In fact I was never able to successfuly forward engineer a database with MySQL Workbench until now. – And that with fairly basic models. For me, this makes Workbench nearly pointless. (Fortunatly I can convert the model to a propel schema for use in PHP and let propel generate the tables. – Propel works better in that regard because it is able to actaually create the same schema flawlessly. )

Since I was not able to successfully create the database, I was not able to test the other features MySQL Workbench offers. These features include creating SQL-ALTER scripts to update an existing database, and directly synchronizing your changes with a database.

Final thoughts

In general MySQL Workbench looks really promising. The available featureset is rich and really helps when developing new databases. However the current release candidate version 5.0.16 is still quite buggy and even fails to do most important features like the forward engineer wizard. Remember: I started with a clean file, added 9 tables with some foreign key constraints, nothing fancy. During normal use I encountered various bugs, where one even leaded to a corrupted file. (Because I said “Save” when Workbench asked to save the document right after the crash. I was first surprised that I could still save the file, but in the end I should have rather said “Forget changes” because the file was busted after saving it.)
So in conclusion it is really likely that you run into similar bugs when *working* with MySQL Workbench, and that is a real pity. I repeat: MySQL Workbench shows great promise, but in the current state it is simply to buggy to be really use. It is also some kind of pointless if important features like creating a database out of the schema simply dont work. But once MySQL figures out the current problems and bugs and succeedes in making this product stable and usable, it will be a great winner for all people working with MySQL.

Things that are possible with MySQL Workbench, but that this review did not cover:

• Working with Views
• Working with Routines
• Defininig Schema privileges for tables & users
• Scripting through the GRT-Shell
• Reverse Engineering existing databases

Features I currently miss in MySQL Workbench:

• Some sort of Revision management with automatic generation/maintenance of SQL ALTER scripts and database versioning
• A Linux/Mac version
• Proper documentation to write plugins

In case you are interested, here is the list of Bugs that I encountered and reported during the creation of this review:

• Crash while editing EER Diagram
• Unhandled Exception when expanding indexes in diagram
• Unknown Exception caught when changing to “Connect to Columns”-notation
• Unhandled Exception when moving mouse after deleting a layer
• Forward Engineer Wizard always fails MySQL-specifc validation.
• Forward Engineer Wizard fails to generate simple databases

What are your experiences with MySQL Workbench? Did you find it similarly buggy, or did it work for you? Have you found out some tricks to work around some bugs? Comment and share your thoughts!

For the intrigued of you: We just changed line 89 of wp-syntax.php to include mouseover and mouseout events on the code-div:

$output = "\n<div class=\"wp_syntax\" onmouseover=\"this.className='wp_syntax mouseover'\" onmouseout=\"this.className='wp_syntax'\">";

There we add and remove a class named mouseover, and styled that class so that the div is wider. Simple, yet effective.

When you work with Ext, sooner or later you will stumble across a design desicion made by the ext developers: Submitting forms is done in the traditional way. This means that the values submitted come from the value field of the input-tag inside the form. This leads to several problems:

• Checkboxes which are not checked are not submitted at all (as normal html-forms also do)
• Comboboxes get their displayed value submitted, and not the value behind the combobox
• DateFields get their displayed date submitted, which may be different based on the users locale
• All Formitems which return something different in their getValue() method from what is written inside the input tags value attribute will probably not be submitted correctly.

Thankfully, after some pondering, I developed a nice solution: OOSubmit!

OOSubmit is a custom Ext.form.Action which submits forms in an object-oriented way. – Hence the name OOSubmit. Instead of going trough the forms input-elements and getting their value attributes, this submit action goes through the form items and calls their corresponding getValue() method. It also looks if the item has a getSubmitValue() method and used that instead of getValue() if present.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

Ext.namespace("Ext.ux");
 
/**
 * This submit action is basically the same as the normal submit action,
 * only that it uses the fields getSubmitValue() to compose the values to submit,
 * instead of looping over the input-tags in the form-tag of the form.
 *
 * To use it, just use the OOSubmit-plugin on either a FormPanel or a BasicForm,
 * or explicitly call form.doAction('oosubmit');
 *
 * @param {Object} form
 * @param {Object} options
 */
Ext.ux.OOSubmitAction = function(form, options){
    Ext.ux.OOSubmitAction.superclass.constructor.call(this, form, options);
};
 
Ext.extend(Ext.ux.OOSubmitAction, Ext.form.Action.Submit, {
    /**
    * @cfg {boolean} clientValidation Determines whether a Form's fields are validated
    * in a final call to {@link Ext.form.BasicForm#isValid isValid} prior to submission.
    * Pass <tt>false</tt> in the Form's submit options to prevent this. If not defined, pre-submission field validation
    * is performed.
    */
    type : 'oosubmit',
 
    // private
	/**
	 * This is nearly a copy of the original submit action run method
	 */
    run : function(){
        var o = this.options;
        var method = this.getMethod();
        var isPost = method == 'POST';
 
        var params = this.options.params || {};
		if (isPost) Ext.applyIf(params, this.form.baseParams);
 
		//now add the form parameters
		this.form.items.each(function(field)
		{
			if (!field.disabled)
			{
				//check if the form item provides a specialized getSubmitValue() and use that if available
				if (typeof field.getSubmitValue == "function")
					params[field.getName()] = field.getSubmitValue();
				else
					params[field.getName()] = field.getValue();
			}
		});
 
		//convert params to get style if we are not post
		if (!isPost) params=Ext.urlEncode(params);
 
        if(o.clientValidation === false || this.form.isValid()){
            Ext.Ajax.request(Ext.apply(this.createCallback(o), {
                url:this.getUrl(!isPost),
                method: method,
                params:params, //add our values
                isUpload: this.form.fileUpload
            }));
 
        }else if (o.clientValidation !== false){ // client validation failed
            this.failureType = Ext.form.Action.CLIENT_INVALID;
            this.form.afterAction(this, false);
        }
    },
 
});
//add our action to the registry of known actions
Ext.form.Action.ACTION_TYPES['oosubmit'] = Ext.ux.OOSubmitAction;

To use this, simply include the code somewhere in your page, and when you want to submit the form dont use form.submit() but form.doAction(‘oosubmit’); This way you may always submit the form in the traditional way.

To make it even easier, i wrote a small plugin which can be plugged into a BasicForm or FormPanel. It overrides the standard submit() action and uses the OOSubmit action by default.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

/**
 * This plugin can be either used on BasicForm or FormPanel.
 * In both cases it changes the behaviour of submit() to use
 * the 'oosubmit' action instead of the 'submit' action.
 */
Ext.ux.OOSubmit=function()
{
 
	this.init=function(_object)
	{
		var form=null;
		if (typeof _object.form=="object")
		{ //we are a formpanel:
			form=_object.form;
		}
		else form=_object;
 
		//Save the old submit method:
		form.oldSubmit=form.submit;
 
		//create a new submit method which calls the oosubmit action per default:
		form.submit=function(options)
		{
	          this.doAction('oosubmit', options);
	          return this;
		};
	};
 
};

To use the plugin, simply constuct a BasicForm or FormPanel and add this to the config:

plugins: [new Ext.ux.OOSubmit()]

- Done.

The checkbox problem and the combobox gets solved by OOSubmit automatically, because the getValue() function is used.

To fix the datetime problem mentioned above I spent Ext.form.DateField a getSubmitValue() function:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/**
 * Returns the submit value of the datefield, always in the same format,
 * regardless of display format.
 * The format returned is Y-m-d, because this is common format used in rdbms. (mysql for example)
 *
 */
Ext.form.DateField.prototype.getSubmitValue=function()
{
    var v = this.getValue();
    if(v !=='')
    {
       var date= new Date(v);
       return date.format("Y-m-d");
    }
    return v;
};

Thats it! Now everything works like it should (IMHO).

Questions, ideas for improvements, bugs?

Update on 2008/03/12:

OOSubmit now also supports baseParams of forms in POST and GET mode, also custom params passed to form.doAction() are now honored.
As mentioned in the ext forums, the code will now discard disabled fields and not submit them as normal.
The bugs mentioned in the comments have also been fixed. The code should now work out of the box.

As already mentioned i use MySQL Workbench to develop the database schema for DiLoc|Rail. Since I got to know Ruby on Rails some years ago, I was reluctant to write the whole database code for the backend of the app manually, I was in search for something similar. Something which does the hard work, so that i can concentrate on the real problems. Since I did not want the whole package as Ruby on Rails is, the Ruby on Rails clones where no option. So I finally found propel. Propel concentrates on the model in MVC (Model-View-Controller) and is an ORM (Object Relational Mapper) For propel to understand your database, you have to write a schema-file in XML. (There is also an option for reverse engineering the database, but I left that out because it has its own problems). Since I already had a model in MySQL Workbench, I needed a way to convert the workbench file to a propel readable schema.

Over the DBDesigner4 to Propel XSL I got to a version for Workbench by Josh Bryan which was a great start, but it only worked with the alpha versions of workbench. I adapted it to work with the beta versions and also improved it quite a bit, to save even more information to the propel schema. Now it supports:

• all datatypes that MySQL Workbench and propel have in common
• propel required attribute
• propel default values
• autoIncrement attribute
• foreign key relations
• multiple indexes, both primary and unique

Since workbenchs file format is really ugly i was not able to let it work properly if a graphical model is inside the workbench schema. This is due to the weird value/link-tag behaviour mentioned in the last article. I’m playing with the idea of writing a plugin for MySQL Workbench to directly save as propel schema, which should be even easier, but documentation on that matter is sparse at best. – But for now, this solution works satisfyingly.

If anyone is interested, write a comment and ask for the XSL. If many people are interested I would also consider to build a small webservice around it so that you can upload your MySQL Workbench file and get your propel schema for download.

So this was the first part in the series. Next time we will look at how to improve that even more and add some glue to the mix.

While starting the project i decided to model the database schema in a handy software, instead of doing all manually and writing SQL from hand. I had discoverd DBDesigner4 earlier and then found out that the man behind DBDesigner got employed by MySQL to work on a successor of MySQL workbench. That also explained why the last version of DBDesigner4 is already quite dated. Since i needed to convert the schema of Workbench into another format (more on that on a later post) i poked around the possibilities. Luckily for DBDesigner4 there was an XSL to convert into something I needed. I figured: Well if Workbench is based on DBDesigner4 the format of Workbench shouldn’t be that different. – False! It is an entire new format. Luckily I found another XSL which worked with the format of the first alpha of Workbench.

It wasn’t that much work to modify it to work with the first beta of Workbench. While modifing the stylesheet i noticed how broken the format is. While DBDesigner4 had a reasonable format, the whole Workbench file only consists of value- and link-tags.

Example of the beginning:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<?xml version="1.0"?>
<data grt_format="2.0" document_type="MySQL Workbench Model" version="1.1.2">
  <value type="object" struct-name="workbench.Document" id="{09E16181-F56F-4679-9BE3-2B3011614FC4}" struct-checksum="0x168c26cf">
    <value _ptr_="091538E8" type="dict" key="customData"/>
    <value type="object" struct-name="app.DocumentInfo" id="{9036684B-D03A-4A4C-ADA3-06389EEAA76A}" struct-checksum="0x6f9ae369" key="info">
      <value type="string" key="author">dhaas</value>
      <value type="string" key="caption">New Model</value>
      <value type="string" key="dateChanged">Jan 30, 2008</value>
      <value type="string" key="dateCreated">Jan 01, 1970</value>
      <value type="string" key="description"></value>
      <value type="string" key="name">Properties</value>
      <link type="object" struct-name="workbench.Document" key="owner">{09E16181-F56F-4679-9BE3-2B3011614FC4}</link>
      <value type="string" key="project">Name of the project</value>
      <value type="string" key="version">1.0</value>
    </value>
    <value type="object" struct-name="workbench.logical.Model" id="{F1F49DC7-983C-4675-925A-8C11ECA4206C}" struct-checksum="0xfe2cd94a" key="logicalModel">
      <value _ptr_="091533A8" type="dict" key="customData"/>
      <value _ptr_="09153570" type="list" content-type="object" content-struct-name="model.Marker" key="markers"/>
      <value type="string" key="name"></value>
      <value _ptr_="091539D8" type="dict" key="options"/>
      <link type="object" struct-name="workbench.Document" key="owner">{09E16181-F56F-4679-9BE3-2B3011614FC4}</link>
      <value _ptr_="0B4A04C8" type="list" content-type="object" content-struct-name="workbench.logical.View" key="views"/>
    </value>

- Okay, i lied. Actually there is even a third tag. The data-tag surrounds the whole document.
As you see, the fileformat is merely a dump of the internal structures of the workbench document. Ignoring the problems that brings when writing stylesheets because you can only match value-tags and the struct-name attribute which makes the whole XSL kinda messy, this even brings some uglier problems with it: The link-tag. The link-tag represents a pointer in the struct. So in the xml it points to another value-tag somewhere above the document.
But the real problem arises now: Since you cannot distinguish the original and a secondary pointer to any object in C/C++. This means that when an object (which is in fact a pointer) is encountered for the first time, it is saved as value, and on subsequent occurences, it is dumped as a link-tag to the original value.

The problem is now, that the occurences of objects varies, depending on the content of the workbench-model. So for example if you have a graphical representation inside your model, all tables are referenced first in the model and thus dumped as value tags. Later on, when the real table definitions are dumped, only links to the already dumped value-tags are generated.
This makes it really painful to develop a working XSL, because you always have to match two cases of tags: either the information you are searching for is directly inside the value tag, or the value tag is absent. Then you have to find the link-tag, take its id and find the original value-tag by this id.

In line 21 of the example you see such a link which actually was a pointer to the compound document around it. In this case it does not really matter because the workbench.Document will always appear first in the file, but unfortunatly everywhere else this is not the case and causes a host of problems when trying to read the XML-format.

Morale of the story: If you plan to develop your own XML-format, do not just dump your internal data-structures, otherwise you could as well dump them in binary form.

In the meantime head over to the about page and inform yourself about DiLoc.

Stay tuned!