Q posted details on the generics support in the binding validator -- here's the rest of the changes to wolips since the last post (in roughly chronological order):
Ant 1.7 is required to use woproject.jar now
Updated default build.xml: compile is always called, framework/app name fully depends on build.properties now, added a package target that will tar up the build products, split install is supported out of the box and is on by default
New EOModel Wizard lets you pick the plugin you want to use (it finds all the reachable plugin frameworks) and automatically adds the framework dependency for you.
Fixes for Windows users.
woproject/ant.* files are no longer necessary and have been removed from the default templates.
Lots and lots of enhancements for maven support.
XML formatting now uses our HTML formatter (which is a lot better than the default)
Lots of new ways to override wolips.properties:
1) you can set wolips.properties= in your build.properties (relative path = loads from ~/Library/Application Support/WOLips/whatever, absolute = ... absolute)
2) you can set WOLips Properties File in the global WOLips Build Preferences (to set a workspace default) -- same rules as #1
3) you can override any settings from wolips.properties in your build.properties (this was supported before, but just reminding)
This should make it easier to experiment with different versions of WO on a per-project (or per-workspace) basis. These changes require either project close/reopen or possibly an eclipse restart.
Better support for models in jar-based frameworks
Support for executing SQL on Oracle
Kind of big change for dependencies -- frameworks must be added to the app level. They are no longer automatically cascaded up the dependency tree. This is required if you want to support things like overriding classes in Wonder in your own code, where Wonder itself also overrides classes in core. Without this, you end up cascading up JavaWebObjects too early and you only get one chance at a "first" framework. Unfortunately, to change this is to rewrite the Eclipse classpath system.
Namespaced attributes are now parsed properly in template html (i.e. something:key="value")
Performance enhancements for automatic EOGen generation (duplicate removal in the queue, support for cancel, etc).
Performance enhancements for Entity Modeler (only models that match a resource patternset are loaded, and some big speed improvements on saving).
LLLOOTS of fixes in Entity Modeler.
Upgraded for Eclipse 3.4.1.
Entity Modeler now only rewrites files that contain changes (for instance, changing an entity will only rewrite that single entity plist).
Entity Modeler now tries to preserve EOModeler syntax for connection dictionaries when it can.
Entity Modeler now has an option to now show relationship optionality warnings (if you have huge models and you get a lot of these, it can be annoying)
Entity Modeler now supports the new custom prototypes naming convention from Wonder.
Tag shortcuts default to include all of the shortcuts from 5.4.
Made the templating system is now much more generic to support more than just project templates (for instance, Component templates).
Added support for project-relative component templates.
Support for custom display group subclasses and generics in the display group wizard.
Support for binding validation and completion of generic types.
Monday, March 23, 2009
Saturday, March 21, 2009
WOLips now knows about generics
Not long ago generic type parameters were added to ERXDisplayGroup in Project Wonder, after which it became apparent that WOLips would need to learn how to interpret the now genericised key paths so that they can be validated and offered as suggestions in content assist and the bindings view. After a few less than successful attempts we are pretty close to having generic type resolution working correctly in the latest nightly builds. This should work for generic typed fields, methods and subclasses.
If you were previously avoiding using generics because WOLips did not validate them correctly then now is the time to reconsider that decision.
If you were previously avoiding using generics because WOLips did not validate them correctly then now is the time to reconsider that decision.
Wednesday, September 3, 2008
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 :)
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 :)
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.
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.
Wednesday, May 21, 2008
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.
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.
Sunday, March 9, 2008
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.
Saturday, March 8, 2008
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.
Subscribe to:
Posts (Atom)
