It's Alive!

NewBuildPathHotness is about to go nightly ... It's not all done, but it's looking usable and useful.

New and Noteworthy

WOLips project properties are split into two sections -- Development and Deployment.



Development settings look about the same with the exception of a new text field "Framework Folder". In this field, you can specify the name of a folder within your project that contains project-local Frameworks (essentially it's like having a Library/Frameworks inside your WOLips project). This is likely a rare setup, but the option is there if you need it. Setting this isn't particularly smooth at the moment -- you probably need to close and reopen your project to have it pickup that change for now.



Deployment settings has several new additions. For one, checking Servlet deployment now automatically adds the JavaWOJSPWhateverItsCalled.framework to your project, so you don't have to do any second steps. For JavaClient people, there is now a checkbox to specify that you are building JavaClient (and then optionally JavaWebStart). The build files for these are based on the ones from the Wiki, and I don't do JavaClient, so those files will probably go through revisions.

Embedding can now be controlled from the panel. You can check which sets of frameworks get embedded in your deployment (incidentally, checking Servlet presumes embedding, so these are disabled).

And now the big one ... Classpath management is completely reworked. If you use jar frameworks or maven, this doesn't really impact you at all (you just ... do ... whatever it is you do, I guess). However, if you use bundle frameworks (i.e. the traditional .framework folders), then this affects you:

* Previously you had to add references to .framework bundles in the WO frameworks section.
* If you wanted to link to the source projects, you would link them also but had to move them above the WO frameworks.
* Framework ordering was not preserved when generating the deployment classpath file (it alphabetized)
* Framework ordering between eclipse runtime and deployment was different.
* If a team member was missing a framework file, the dependency was removed upon checkout, which would break deployment when s/he committed again.
* woproject/ant.* files are generated on each developer's machine, which can be different for everyone and different than deployment.

The new system addresses all of these. Some power and flexibility is removed, but in exchange for much greater ease-of-use.

* Frameworks now behave like normal Libraries in Eclipse:


* The system tracks where a framework is located dynamically. If you open a framework project, all projects that reference the framework are dynamically rebound to the project. If you close the project, all referencing projects are rebound to the /Library/Frameworks (or the next lower in the precedence) version:



* Frameworks are independent Libraries in the build path, so you can reorder them independently. This is only SOOOORT of true, however, because both the ant build and the runtime system need to reorder your build path to make sure that launching proceeds correctly (for instance, Apple System frameworks will always be ordered below Library Frameworks at launch and deployment, but ordering of Library Frameworks will be preserved).

* The code for computing the build path order is shared between Eclipse and the Ant tasks, so the ordering is consistent.

* The ant tasks now parse eclipse .classpath files to determine build path order (and the format of this file is easy enough that you could generate this from other IDE's or build systems), so there is a single project artifact for specifying this in both places.

* On a related note, resource and wsr patternsets are now properly shared between the ant build files and Eclipse, and should evaluate in the same way.

* woproject/ant.* files are gone. Dead and gone. Forever. No more conflicts. No more missing frameworks. No more NullPointerException from UpdateClasspathIncludeFiles (that is also gone).

* If a framework is missing, the classpath is preserved, but the build path will just be broken. Missing framework does not equal framework removal from the project files.

* ~/Library/wobuild.properties is now cleansed of weird duplicate data and lives in (by default) ~/Library/Application Support/WOLips/wolips.properties along with all the other WOLips artifacts. The file will be autogenerated for Windows and OS X with the correct default values and should just work out of the box.

* Project build.properties can override wolips.properties settings now. There is no UI for this yet, but you can manually override the wo system root, wo local root, on a per-project basis, which allows you to build some projects against WO 5.4, and some against 5.3 (for instance). This probably also requires a close-and-reopen, but at least it's possible now. I haven't tested this with the ant builds yet, so I'm not positive the precedence of those two files is correct, but it should be close.

Conversion
Within Eclipse, the first time your project opens in the new system, your .classpath will be autoconverted to the new format. woproject/ant.* files are not deleted automatically, but they are no longer used and are safe to delete.

For the build system, the easiest route is probably to generate a new Wonder App (or WO App, or framework, or whatever) and copy the generated build.xml into your projects to try out. For projects using the Fluffy Bunny Layout (with correct FBL woproject patternsets -- copy these from a new project if you don't know for sure), this should "just work" (assuming you don't do anything out of the ordinary).

One nice side effect of this is that if you don't deploy from your Eclipse machine (meaning, you have a build server), you don't need any WO frameworks installed in /Library/Frameworks -- You can JUST have project frameworks and things will work. So if you are checking out Wonder, you no longer have to remember to have the /Lib/Fram versions relatively up-to-date, too.

Note that ant building does NOT cross project boundaries. To do a deployment (ant) build, you will still need frameworks built into the folders specified in your wolips.properties (or build.properties). This is a nasty problem and very hard to solve in the general case, but we might address this later.

I would expect this to go to nightly sometime this weekend. This is to be considered UNSTABLE. I have been building against it and using it for about a week, but this is a LOT of new code that touches a LOT of both the wolips runtime as well as the ant build system. It will have problems, and I can almost assure you that if you have some sort of crazy custom build.xml that you'll run into them. Going forward, you will be rewarded for drinking our kool aid. If you buy into things like the standard project layouts and build files, you life will go smoothly. If you don't, your life will go less smoothly.

That is all :)

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.

This (now-lastPost.time) In WOLips

Thanks to the many additional contributors we've had in the past few months -- Quinton Dolan, Andrew Lindesay, Lachlan Deck, Henrique Prange, David Avendasora, as well as the usual crew (and if I missed anyone, I apologize). The changes below represent the cumulative efforts of everyone. Currently these changes are only available in the nightly build. This will probably be moving to stable prior to WOWODC.

API Editor
API editor has been visually redesigned to hopefully make it easier to use. "Required" and "Settable" actually ... work properly now. Also, required bindings appear bolded in the binding list. There is still not an editor for complex binding validations, but Entity Modeler is getting a graphical qualifier editor (visually "inspired" by Core Data Modeler) that hopefully can be used to render/edit binding validations also.


You can now open API files in the API editor that do not have a corresponding WOComponent.

Component Editor
Completion works on Direct Action class names, Direct Action names (though it's not quite smart enough to know which DA's to restrict to based on the Direct Action class name, yet, so you'll get all DA methods shown as completion proposals), page names, framework names, resources, and actions. Resource completion is sort of sketchy as well, because the code isn't passing through flattening rules. I think if you use Wonder-style projects it should work out. If you flatten, it probably won't. All of these completion types require that your API files are defined properly with the appropriate binding type.

Component Live Search should work much better on Windows now.

Lots of fixes and cleanups in the Component Creation Wizard (particularly related to character encodings).

The default application and framework templates set the encoding of Components to UTF-8 by default.

Refactor=>Renaming components properly renames all the component files (java, api, etc). Previously this worked if you renamed the Java file but not if you renamed the WO.

Lots lots lots of fixes and enhancements to formatting component HTML. It should be MUCH better now.

Your selections in the Add Key/Add Action dialogs are preserved across executions now.

"Add Key" without an accessor creates a public ivar now.

Component validation runs in a background thread. This prevents the component editor from blocking the opening of your component while it performs a relatively expensive binding validation. There are still a little wonkiness with this -- every once in a while I lose my validations on a component until I resave it, but the performance increase for opening components is pretty substantial.

Initial support for Groovy components (Q can provide more info on this).

Keypath completion works inside of OGNL bindings.

Obnoxious long-standing bug where keypath completion would not work on values of unknown attributes is finally fixed.

Entity Modeler
SQL Generation properly passes through the necessary flags for index in 5.4 (though this requires 5.4.2).

Entity Modeler can now load EOModels from inside of jar frameworks.

Entity Modeler is much slicker about how it does live rename syncing. If you use infix caps, prefix caps, underscores, all uppercase, all lowercase, and several combinations of these, synced renames understand that. For example, if your attribute is named "firstName" and your column name is "first_name" if you rename the attribute to "personFirstName" it will sync-as-you-type the column name to be "person_first_name". It will also try to guess what it should use based on other attributes and entities in your model. There are still some things it misses, but it should be a much citizen in non-infix-caps database environments.

You can now provide a "parent class override" for an entity. This class will be set as the parent of your _Entity class. For instance rather than the EOGenericRecord-variant (which allows for per-entity custom "generic record" classes). This is set in the Advanced Entity Properties dialog.

The new relationship dialog has been redesigned. There's ONE more redesign coming to clarify the order of operations if you don't want to create an inverse relationship:


Entity Modeler now provides an option for selecting the REST adaptor (for Wonder's JavaRESTAdaptor).

Attributes and relationships now expose a "common class property" flag that can be used in eogenerator to generate methods that are shared between client and server classes for Java Client.

It's not available yet, but a graphical qualifier builder that will function pretty similarly to the predicate builder in Core Data Modeler is almost ready. This will allow you to build qualifiers completely without touching the big text area.

If you use Wonder and the Migration API, you know how annoying it can be to write your "zero" migration -- you spend all this time modeling your entities, and then you have to turn around and manually build the zero migration with the API. Entity Modeler can now generate a zero migration for you. Just select the model or set of entities to generate and click the "Generate Migration" button in the toolbar or the context menu and it will spit out:



EOGenerator
Entity Modeler and Velocity EOGenerator have exposed several new features for making it easier to write eogenerated Java Client classes.

EOModelDoc
EOModelDoc shows a list of all entities that reference an entity at the top of the entity docs.

EOModelDoc shows a list of all sub-entities at the top of the entity docs.

Building
The long-standing bug with component patternsets evaluating incorrectly on Windows has finally been fixed.

Maven (bear with me here, I don't use Maven, so these are mostly transcribed)
WO Maven plugin now has "install" and "deploy" goals.

woboostrap adds WO 5.4 libraries now.

New archetype for WebObjects applications conforms to new archetype plugin

Rule Editor
There's been a D2W rule editor inside of WOLips for a long time, but it's always .... well it's just been really broken. Finally the reigns have been picked up and a still-alpha, but functional rule editor plugin has been committed. So if you're not on OS X and can't use RuleModeler, you actually have some hope of a refreshed editor showing up.

Thanks again to everyone who has been involved. It's been very nice seeing submissions from several new faces, and we have plenty of ideas left to implement and more cool things coming.

Bindings View

In the new Bindings View browser, keys and actions are grouped by type, in reverse order of inheritance tree depth. So, for instance, in your component, your custom components keys appear first, then your component's superclass, then WOComponent, etc. For model objects, your custom methods appear, then your _Class methods, then ERXGenericRecord, then EOGenericRecord, etc. This should help address the desire to show the mostly important bindings first (those being the ones that are directly on the class you're talking to), but also provide access to more specialized custom bindings.

The bindings inspector shows all the available bindings for a component, and turns red the ones that are currently invalid. Both the key and values are editable by double-clicking in the cell, or by dragging bindings from the browser onto the table view. You can also create new bindings with the "New Binding" button and remove existing bindings with the "Remove Binding" button (or by blanking out the value of a binding with the editor). Lastly, if you define a missing key or action as the binding, you can select it and click the "Add Key" button to go through the Add Key/Add Action dialog.

Here's an example of a binding name in editing mode.

And here is a snapshot of a binding being dragged to the inspector view. You can also drag onto HTML or WOD entries in the same way.

Here's dropping onto a binding in the HTML view.

And last, but not least, there are new Delete Tag and Unwrap Tag actions in the editor. Delete tag will remove the tag you're under, and all of its contents. If the tag is a WO tag, it will also remove the WOD entry if this is the last tag reference to it. Unwrap tag is the same, but only removes the tag and does not remove the tag's contents.

Note that all of these features are still Experimental (they are rewriting your WOD and HTML documents, which could mean they could decide to EAT your WOD and HTML documents). To try them out, grab the latest nightly and go to Window=>Show View=>Other... browse down to the "WOLips" category and select "Bindings (Experimental)".

One element that isn't quite there yet is undo ... Right now undo is handled separately in the WOD and HTML, so if you perform an operation that requires rewriting both, you will need to undo in each to undo the changes. I'm working on trying to figure out how to do a composite undo manager, but it's not there yet.

Check out the videos in the previous posts to see some of the slightly older versions of these features in action.

Sneaky Peek 4

I think this is the last one: drag-and-drop onto inline, onto WOD, and onto the bindings inspector. I need to add a column editor onto the inspector view so you can type keypaths and literals into it as well, but that should be pretty easy.

Sneaky Peek 3

It's not hooked up to .wod files yet, but for inline bindings, it's available in nightly.

P.S. My tab color isn't actually bright red, that's just what I have set when I run my plugin development Eclipse.

Sneaky Peek 2

Just because we're in Eclipse doesn't mean we can't be fancy.

WOLips 3.3 Stable!

Eclipse 3.3.2 is out, which has been holding us up releasing a stable WOLips for months.

We are pleased to finally announce the new stable build of WOLips based on Eclipse 3.3.2! WOLips 4118 (the previous stable build) was deployed June 26, so there are eight months (and 7000 lines of changelog entries) worth of coolness that have been going into the nightly builds just itching to get out.

Thanks to Ulrich and Anjo and our new committers from this year Daryl, Pierre, and Quinton for all the hard work.

And now for the disclaimer: The new build requires Eclipse 3.3 and is no longer compatible with Eclipse 3.2, so you will need to update your Eclipse as well as install the new WOLips. Eclipse 3.3.2 has not made it to the main download page on eclipse.org, yet, but you can download it from the direct download page.

The wiki installation tutorial has been updated for Leopard and Eclipse 3.3.2 here.

And the list of changes ...

Moved to Eclipse 3.3
Entity Modeler
* Converted to 3.3 Data Binding
* Substantial performance optimizations
* Standalone Entity Modeler
* Standalone Entity Modeler - Supports loading dependencies from IDEA projects
* Better focus management
* No more silent model loading failures
* Supports editing the entire model group together, not just a single model
* No more EO icons in non-EO perspectives
* Fixes for Vertical Inheritance Wizard
* Optionally hide non-class properties in Outline (on by default)
* Changing mandatory relationship flag changes allows-null and vice-versa
* More lenient qualifier parsing
* Reflexive many-to-many relationships in the Relationship Wizard
* Lots of visual cleanup
* Edit-in-place in Entity Modeler outline view
* MUCH better error dialog that supports jumping directly to the error
* MUCH faster plist parsing
* Renaming attributes and relationships updates dependent flattened properties
* Support for Project Wonder's partial entities
* Support for Project Wonder's JavaMemoryAdaptor database
* Backwards-compatible with EOModeler and CVS-stable plist format
* New option to not generate source for particular entities
* Gray out non-class attributes/relationships
* Remove jdbc2Info prior to SQL generation
EOModelDoc
WO Package Explorer
* The "sometimes I don't hear double-clicks" = Gone
* Display EOModels and Components as bundles
Profiling
* JProfiler 5.0 Support
Component Editor
* Ignore cmd-opt-1 when you're already in Java
* OGNL expressions are colorized separately
* Only show API bindings if an API files exists and is non-empty
* Added API binding declarations for id, style, and class onto all the WO core components
* Allow accessing to protected variables in packageless classes
* WO hyperlinks in the HTML editor
* Clicking WO hyperlinks open Java and Component
* WOO / Display Group Editor
* Experimental HTML Preview
* WO tags are colorized separately
* Fix for stupid missing HTML Editor preferences labels
* Component Outline View (inspired by WOB and Xylescope)
* Experimental Bindings Inspector
* Overview ruler available in HTML editor
* LOTS and LOTS of fixes to the fuzzy template parser and model
* Lots of performance work (though we do a lot more now, so YMMV)
* Weird occasional won't-go-away errors should go away now
* Support for binding name and binding value hyperlinks
* Support for component name completion in binding values (like WOHyperlink pageName)
* Better error handling during SQL generation
* Many more preferences for component validation
* Validation and formatting fixes for Javascript
* Integrate WOO file encoding declarations with Eclipse resource encoding
* Support for // VALID on inline bindings (only with Wonder's inline binding parser)
* Preference for spaces-and-equals during reformat
* Language labels on multilanguage component tabs
* Experimental support for drag-and-drop of Components from WO Package Explorer into HTML editor
* HTML breadcrumb trail ala WOB
* Height of WOD portion of split pane saved across editors
* WOD split pane can be (almost) fully collapsed
* cmd-click on missing / broken bindings opens Add Key or Add Action dialogs (ala WOB)
* Experimental Bindings Browser
JDT and Building
* Removed the oldest classpath container
* Lots of fixes for making SSDD builds easier
* Preference for turning on/off exception-helper dialogs
EOGenerator
* Added support for JavaEOGenerator
* Added Velocity EOGenerator
* Fixes for Windows
* Support for custom packages for _File files
* Support for easily Override-able templates
Wizards and Templates
* Improved every wizard
* Added D2W app and D2WS app wizards and templates
* Added support for custom project templates and override-able project templates
* Support for setting doctype and encoding in component wizard
* All projects now use the Wonder-style project layout (aka Fluffy Bunny Layout)
* Fixes for Windows in project templates
Workspace and Problems View
* Support for tagging components with logical organization
* Template Problems appear in their own category
* Lots of improvements to the component locator
* "Open Component" action (cmd-shift-x ... i know ... c was taken)
* Added Console to the default WOLips perspective
Misc
* New WOLips web service to support external tool integration
* WOLips.framework in project Wonder provides browser click-to-open support for components

Eclipse 3.3.2 is Out

It's not officially announced, but the new release version of Eclipse is now 3.3.2:

http://download.eclipse.org/eclipse/downloads/

Sneaky Peek

And for the record, Eclipse REALLY doesn't want you to be able to do these things. Note that this is not ready for usage, it's just a peek at what will be coming in a future release.

Entity Modeler.app v1.0.3

The latest build of Entity Modeler.app is up at the mDimension build site: Entity Modeler 1.0.3.dmg

This brings Entity Modeler standalone back in parity with mainline WOLips nightly.

WO Browser

This is very experimental right now (read: if you mangle your component playing with it, I'm innocent), but the Bindings editor now has a binding browser ala WOB:

You can see a shot of my eclipse with everything going on (which just kind of looks cool) at  http://skitch.com/mikeschrag/g5y6/latest-wolips

Drag-and-drop linking of bindings onto tags is on its way, too (complete with line drawing on top).

New Stuff

OK .. Yeah, I know I wasn't going to add things until after the classpath changes, but classpath management is no fun, so ...

Template Bread Crumb Trail

As you navigate around your template, the breadcrumb updates. Single-clicking selects the particular element, double-clicking opens the particular component (if it's a WO). There's also a slightly different styling for the sash -- a darker line, vs just a same-color-as-background bar, so it's more obvious where you need to grab to resize the sash.

WOD/HTML Sizing

When you shrink the WOD view down below its minimum size it will now blank out (rather than just be a garbage-looking compressed form. Additionally, the size of the WOD and HTML portion of the component editor is saved when you make changes, so if you only use inline bindings, you can resize the HTML view to its maximum and you don't have to mess with it ever again.

If you have have compressed your view but your wod is not empty, it will give you a hint letting you know, so you don't accidentally miss something:

Bindings Inspector (Not Finished)

The bindings inspector (ala WOB) is in the WO Perspective by default now (you can Reset Perspective to pick it up, along with Console, which is now added by default). Currently you can only edit the component name and type, but the rest should be coming soon. This refreshes as you navigate around the template as well. Name and type only commit when the text field loses focus at the moment -- I might that to a live update, though.

Add Key / Add Action

If you cmd-click on a missing binding value in a WOD or inline binding (restricted to keys, not key paths), it will open the Add Key or Add Action dialog. The determination of which to open right now depends on having a correct API file that defines the type as "Actions," or in the absence of a correct API file, any binding named "action" will open the Add Action dialog.
I don't have a WOB available, so I just had to guess at exactly what all the settings do, but the behavior should be reasonable. The list of types in Add Key come from your model (which I think is how WOB worked, though I suspect we should support more generalized type selection). You can type any class name in the type field and it will resolve it, so it doesn't HAVE to be an entity name. You also don't have to fully qualify the name -- if it can resolve the packageless name without ambiguity it will use it.

If you select Array of Mutable Array of ... and your project it set to a source level of 1.5+, it will use generics on the NSArray. Similarly for Add Action, if you are using 1.5+, it will use Wonder's ERXComponent shortcut "Whatever nextPage = pageWithName(Whatever.class);". I might add a Wonder-specific check, but you should add that shortcut from WOnder into your component classes, anyway, because it's really nice :)

Right now the type combo doesn't have any options in it -- that will be coming. So you have to just type the name. If you choose WOComponent or WOActionResults it will generate a method that just returns null rather than attempting to lookup a component.

You can also get to Add Key... and Add Action... via the Edit=>Refactor menu rather than cmd-clicking a missing binding value, btw.