Monday, June 16, 2008

This 3 Weeks In WOLips

If you run OS X Leopard, the implementation of the workspace refresh provider has switched from the default polling to one based on the Leopard File System Events API (this is basically the same API that lets Finder refresh immediately when you make a change to your files). This should result in vastly better performance (no more polling = less laptop fan :) ) and refreshing should be very fast. The implementation currently has a 1 second max delay (to allow for coalescing), though I might drop this lower after some testing. This means that after touching the filesystem, it will be at most 1 second before the change appears (and possibly nearly immediate). There is a little more work to do, however, because the default eclipse implementation of responding to a refresh command is to do a subtree scan, whereas with FSEvents we actually know whether or not we have to do that (at best, and usually the case, we only need to do a single container scan). This is going to take some API changes in Eclipse to support this change, though. Even without that, it's still pretty good, though, as most of your time is spent changing files in packages and components (which tend to not be deep trees). The worst case of this is if you change a file in the project root, which will essentially be no worse than the previous implementation (well, better because it doesn't CONSTANTLY do it).

So the downside of this is that there's a new hunk of JNI code in there, written by a mostly-Java-guy, so there's potential for a series of explosions. I've been using it for a little while now without any problems, and the high-risk points are usually startup and shutdown, so you'll probably know pretty fast if it breaks. So if you install the new build and your Eclipse dies on you .... I might be partially responsible. Let me know.

Enable this by turning on "Refresh Automatically" in Preferences=>General=>Workspace.

Entity Modeler
Support for column and table names with spaces in them when surrounded by square brackets (for SQLServer support).

Support for flagging "common" attributes that are shared between JavaClient and server classes (to support a three-layer class structure of JavaClient classes).

New validation for invalid "propagates primary key" flag on to-many relationships with a single pk.

SQL Generation properly loads database plugins from Eclipse project frameworks, and the classpath should fully match runtime now.

Custom attribute and entity prefixes and naming formats can be specified in model properties so that attribute/entity name syncing uses your own preferred format.

Entity 1.0.5 has been built (which includes all of the above)

Bunch of fixes.

Converted Wonder templates to extend ERXComponent and removed generation dates from templates.

Converted the Wonder app/framework template to Wonder 5.0 package names.

Component Editor
Creating Display Groups now creates the corresponding Java code entry (and renaming performs a refactor on the Java).

If the 5.4 preference is checked, the Bindings Editor view will generate inline bindings with $syntax.

Added localizer. and nonCachingContext. to the default binding validation patterns.

Binding key namespaces are now supported by the validator (namespace:keyname = "value"). The namespaces are not actually validated yet, and the values themselves are still interpreted as keypaths, but it shouldn't be a complete fail anymore.

The EOGenerator file editor has a new option "Load Model Group" above the reference models section that should make life much easier. When checked, rather than requiring ref models to be declared in the eogen file, it will instead just load ref models just like Entity Modeler would (that is, using project dependencies). If you check this, you should probably remove your existing refmodels. This is also now the default for new eogen files.

The Wonder veogen templates have been converted to Wonder 5.0 package names.

EOGenerator files can specify a generated file extension now to override the default of ".java". This allows Veogen to be used to generate .m, .h, and Flex .as files without going through a rename step.

The "Create Packages" checkbox is now respected by veogen. If you want to generate, for instance, .m/.h files with veogen, you would not want packages to be generated.

Apple has contributed a Maven plugin to correspond to their recent announcement of public nightly build repositories for WebObjects. More information is available on the WOLips Wiki.