| I too have mixed feelings about WOBuilder. With all its bugs, it is still faster to bind a WOString to Session.observatory.controlRoom.telescope.positioningInstruments.currentPointingModel.declination using WOBuilder then type it.... And it is less error prone...
I do not like making announcements like a Microsoft sales rep and never keep them, but I will make an exception. When the Leopard seed came first out, I (as usual) started investigating all new goodies by trying to develop a moderately difficult application. This time my seed came almost the same time as Cliff's late summer announcements, so I naturally decided to write a WOBuilder replacement :-)
How far am I? Well, I can already do the operation I described above using my app. Not much more, but for something I spent not more then 30 min a day not that shabby too. On Jan 22, 2007, at 1:17 AM, Clark Mueller wrote: The interesting thing about OG's graphing is that someone actually spent some time working on it for the most recent release of OG, to the point that it actually maps attributes now (where previously it only did the entity names). It would be nice if OG were to pop up a window asking how to build and layout the graph that it builds, giving more control over the formatting, etc. Personally, I like to print out my models on 3' x 6' charts, but I don't do it very often, because i don't care to sort through the generated graph and make it fit every single time. So OG is definitely a nice solution, and I'm glad to see that it's doing attributes now, but it has a few shortcomings (although some of these are probably general OG usage issues that I shouldn't be bringing up). Also, I assume that OG itself also uses the Cocoa-Java bridge, unless it's just reading the raw .plist files (anyone know?), so it may too end up a victim of the deprecation.I have mixed feelings about WOBuilder. It definitely needs serious help. Very serious help. But I personally must be missing why it's really THAT hard to strip some of the Cocoa-Java portions of these apps out of them and make them pure Objective-C. In EOModeler's case, I understand that it relies very heavily on the EOControl layer straight out of EOF, and in that case, Mike has obviously built what is basically a fully functional and, IMO, superior replacement to it. WOBuilder is a different beast. I fail to see why it relies heavily on Cocoa-Java APIs, and what prevents it from being updated to be pure Objective-C, getting its attribute and entity information, say, from parsing the .java source files and plist files in the EOModel based on a file change notification, for example.
Obviously I say all that without the benefit of any knowledge of the structure of the app, but it is a tool that I hate to see go away. For me, visual editing is in fact a big boost to my productivity. I will concede that it has certainly resulted in my developing better code, but hand coding still slows me down a great deal. I don't have a "design" team using GoLive and a "development" team using <insert IDE here> that work independently of one another. Apple does, and I think that its own internal development processes involving WebObjects have been adversely affecting development of WOBuilder for a while. What would be kind of nice is if they released the source code for WOBuilder to PW, let's say, so that the community could try tackling this issue. I can dream, right?
Cheers, Clark On 21 Jan 07, at 4:52 PM, Galen Rhodes wrote: Yea, I tried that trick. It's not the same. The results were less (much less) then I'd hoped for. Granted it worked, but in a very utilitarian sense. And, quite frankly, the results were very ugly.
Georg Tuparev Tuparev Technologies Klipper 13 1186 VR Amstelveen The Netherlands Mobile: +31-6-55798196 |