Monday, June 16, 2008

This 3 Weeks In WOLips

General
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 Modeler.app 1.0.5 has been built (which includes all of the above)

RuleEditor
Bunch of fixes.

Templates
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.

EOGenerator
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.

Maven
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.

13 comments:

Robert Huber said...

Hi

I just downloaded the standalone version of the Entity Modeler 1.0.5. Unfortunatly, I still get the error:
org.objectstyle.wolips.eomodeler.core.model.EOModelException: There was no valid EOF ClassLoader factory defined.

I use Servoy as a IDE. But the question about not being able o generate SQL code concerns the standalone Entity Modeler, so there should be no dependencies to any IDE, or am I missing something?

Best regards, Robert

Mike Schrag said...

You are missing something :) There has to be a dependency on an IDE to do many things with Entity Modeler ... Your IDE project files define which frameworks you depend on and where they are located (specifically the WO frameworks). Framework dependencies are required to locate all the models that are in your model group as well as the jars that are required to perform operations such as SQL generation. Without an IDE project file, none of this can be properly resolved.

Robert Huber said...

Hello Mike

Ok, but I think there is nothing needed to generate SQL code. The developer info entered into the Entity Modeler (or EOModeler) is enough to generate SQL code.
What IDE possibilities do I have to install to make Entity Modeler work? I thought as a standalone tool it would not need anything else?

Thanks and best regards, Robert

Robert Huber said...

Hello Mike

As an addendum to my previous message, I like to say that we have WebObjects installed on our Macs.
But that doesn't seem sufficient.

Thanks for advice what to install to make EM work.

Regards, Robert

Mike Schrag said...

SQL code is generated with EOF, which means Entity Modeler has to be able to locate 1) your WO frameworks, 2) your database plugins, 3) your model dependencies (i.e. other models that your model depends on), and 4) application-specific overrides for SQL generation (i.e. if you use Wonder, you want EM to use those same API's).

There has to be a "manifest" somewhere that tells EM how to locate all of this information. EOModels really can't stand on their own and be functional, and guessing isn't really sufficient for a modern build environment (where you often have dependent models and plugins defined in runtime projects, not in installed frameworks). So when I talk about "supported IDE's", what I ACTUALLY mean (just not being rigorous with my terms) is "supported IDE project metadata files".

There is an extension point in Entity Modeler that lets you write custom providers for these API's. We implemented one that can read Eclipse project files, and Apple funded the development of one that can read IDEA project files.

Oh, right, there's actually a 3rd implementation that you could use in your situation, where you can provide a "simple" manifest in the form of a text file located in a few places, but it was never documented:

You can define an EntityModeler.classpath or .EntityModeler.classpath inside the model, in the folder that contains the model, in your home directory, or in ~/Library/Preferences. In this file, you can list either direct jar references to classpath, or /Library/Framework/Whatever.framework references (and it will include all the jars inside the framework) one per line. This file is used for Reverse Engineering and for SQL Generation (to construct the classpath to EOF)

Similarly you can define an EntityModeler.modelpath (with all of the same locations checked) where each line contains a root path to be used to search for dependent models (for instance, if you use ERPrototypes, you could list /Library/Frameworks/ERPrototypes.framework).

So this would be the fallback method if your IDE's project files aren't supported directly.

Robert Huber said...

Hello Mike

Thanks a lot for your explanation! It's very much appreciated!
As our IDE is Servoy (www.servoy.com) and it's going to be Eclipse based in the next version, i. e. version 4, we will use Eclipse (anyway) and therefor the current problem doesn't exist anymore. So we will be able to move all Macs to 10.5.x what we can't do right now as EOModeler does only work with 10.4.x as you know of course as well :-)

Using EOModeler since Version 1 of Mac OS X (the one that looked still as OS 9) and being quite happy (except all the wishes we had .-) I am looking forward to EM and I am very glad to have such a promising tool!

Best regards, Robert

jj said...

I have tried the AJAX test programm but it is not there?

http://www.mdimension.com/cgi-bin/WebObjects/AjaxExample

It worked a couple of weeks ago.

Best regards, Jens

jj said...

Hi,

I tried to use the AJAX examples hosted at mdimension.com but the application is not there!?
It worked a couple of weeks ago.

Is that on purpose or just a crash of the application?

Best regards

Jens Schulze

jj said...

Hi,

I tried to use the AJAX examples hosted at mdimension.com but the application is not there!?
It worked a couple of weeks ago.

Is that on purpose or just a crash of the application?

Best regards

Jens Schulze

jj said...

Hi,

I tried to use the AJAX examples hosted at mdimension.com but the application is not there!?
It worked a couple of weeks ago.

Is that on purpose or just a crash of the application?

Best regards

Jens Schulze

jj said...

Hi,

I tried to use the AJAX examples hosted at mdimension.com but the application is not there!?
It worked a couple of weeks ago.

Is that on purpose or just a crash of the application?

Best regards

Jens Schulze

jj said...

sorry sorry for the duplicate entries. I did not read the top line!

Tech010101x said...

For the Ajax Examples, try this URL: http://webobjects.mdimension.com/cgi-bin/WebObjects/AjaxExample instead.