Re: Classpath State of the Union
On 13/11/2007, at 12:13 PM, Kieran Kelleher wrote: Lachlan, AFAIK, if 1.5 is present on the system somewhere, even if not default (if using OS X Tiger Server with 1.4 as default for example), then you can specify the path to the java executable in the MacOSClassPath.txt in the woa and still run under 1.5 even if 1.4 is the default for the system. Just a thought in case that might be of use to you. Thanks for the thought :-) But alas, it is *not* on the deployment servers at all. They're not macs... and so the question below remains. On Nov 12, 2007, at 7:10 PM, Lachlan Deck wrote: Quick question, On 13/11/2007, at 4:14 AM, Mike Schrag wrote: Lots of people have been plagued with classpath oddities (especially the Session and the Main class one matching javamail and log4j respectively). After much digging, the "official unofficial" causes seem to be: 1) When launching from Eclipse, bundle loading works a little differently, and I believe Anjo's fixes to WOLips should have this resolved now. 2) When launching from Commandline (... including deployment), there are several nasty buggers at play: 2a) Whether or not you are embedding frameworks, check your .woa's Info.plist. If it defines the key Has_WOComponents (whether or not it says true, just whether it exists), this is a bug. At some point in WOLips, the default Info.plist template was modified to include this, and it causes .woa bundles to be identified as frameworks by the NSBundle loader. Ordinarily, classes are loaded from .woa bundles first, followed by frameworks. When Has_WOComponents is set, it appears that the .woa gets lumped in with the frameworks, and it actually loads last instead of first. So delete this key and value if it's in your .woa and it should save you some pain. (currently stuck with Wonder-4.0.0 due to our deploy servers still on jvm 1.4...) Is it equally safe to ditch that key/value from a *.woa when using Wonder-4.0.0? Thanks. with regards, -- Lachlan Deck ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Classpath State of the Union
Lachlan, AFAIK, if 1.5 is present on the system somewhere, even if not default (if using OS X Tiger Server with 1.4 as default for example), then you can specify the path to the java executable in the MacOSClassPath.txt in the woa and still run under 1.5 even if 1.4 is the default for the system. Just a thought in case that might be of use to you. Regards, Kieran On Nov 12, 2007, at 7:10 PM, Lachlan Deck wrote: Quick question, On 13/11/2007, at 4:14 AM, Mike Schrag wrote: Lots of people have been plagued with classpath oddities (especially the Session and the Main class one matching javamail and log4j respectively). After much digging, the "official unofficial" causes seem to be: 1) When launching from Eclipse, bundle loading works a little differently, and I believe Anjo's fixes to WOLips should have this resolved now. 2) When launching from Commandline (... including deployment), there are several nasty buggers at play: 2a) Whether or not you are embedding frameworks, check your .woa's Info.plist. If it defines the key Has_WOComponents (whether or not it says true, just whether it exists), this is a bug. At some point in WOLips, the default Info.plist template was modified to include this, and it causes .woa bundles to be identified as frameworks by the NSBundle loader. Ordinarily, classes are loaded from .woa bundles first, followed by frameworks. When Has_WOComponents is set, it appears that the .woa gets lumped in with the frameworks, and it actually loads last instead of first. So delete this key and value if it's in your .woa and it should save you some pain. (currently stuck with Wonder-4.0.0 due to our deploy servers still on jvm 1.4...) Is it equally safe to ditch that key/value from a *.woa when using Wonder-4.0.0? Thanks. with regards, -- Lachlan Deck ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists% 40mac.com This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Classpath State of the Union
Quick question, On 13/11/2007, at 4:14 AM, Mike Schrag wrote: Lots of people have been plagued with classpath oddities (especially the Session and the Main class one matching javamail and log4j respectively). After much digging, the "official unofficial" causes seem to be: 1) When launching from Eclipse, bundle loading works a little differently, and I believe Anjo's fixes to WOLips should have this resolved now. 2) When launching from Commandline (... including deployment), there are several nasty buggers at play: 2a) Whether or not you are embedding frameworks, check your .woa's Info.plist. If it defines the key Has_WOComponents (whether or not it says true, just whether it exists), this is a bug. At some point in WOLips, the default Info.plist template was modified to include this, and it causes .woa bundles to be identified as frameworks by the NSBundle loader. Ordinarily, classes are loaded from .woa bundles first, followed by frameworks. When Has_WOComponents is set, it appears that the .woa gets lumped in with the frameworks, and it actually loads last instead of first. So delete this key and value if it's in your .woa and it should save you some pain. (currently stuck with Wonder-4.0.0 due to our deploy servers still on jvm 1.4...) Is it equally safe to ditch that key/value from a *.woa when using Wonder-4.0.0? Thanks. with regards, -- Lachlan Deck ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Classpath State of the Union
Am 12.11.2007 um 18:14 schrieb Mike Schrag: 1) When launching from Eclipse, bundle loading works a little differently, and I believe Anjo's fixes to WOLips should have this resolved now. Be aware that the current fix reorders the debug or runtime classpath to move App and Project jars/classes up front, then apple classes, then non-WO jars to the back. Unless you either use Project Wonder or are doing similar stuff as we do in ERXApp.setup(), your Eclipse patch will be very different from your deployment/ant classpath! Cheers, Anjo ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Classpath State of the Union
Lots of people have been plagued with classpath oddities (especially the Session and the Main class one matching javamail and log4j respectively). After much digging, the "official unofficial" causes seem to be: 1) When launching from Eclipse, bundle loading works a little differently, and I believe Anjo's fixes to WOLips should have this resolved now. 2) When launching from Commandline (... including deployment), there are several nasty buggers at play: 2a) Whether or not you are embedding frameworks, check your .woa's Info.plist. If it defines the key Has_WOComponents (whether or not it says true, just whether it exists), this is a bug. At some point in WOLips, the default Info.plist template was modified to include this, and it causes .woa bundles to be identified as frameworks by the NSBundle loader. Ordinarily, classes are loaded from .woa bundles first, followed by frameworks. When Has_WOComponents is set, it appears that the .woa gets lumped in with the frameworks, and it actually loads last instead of first. So delete this key and value if it's in your .woa and it should save you some pain. 2b) If you embed frameworks, there is a bug in NSBundle that causes all jars within your application to load in as part of the .woa. So each framework loads its jars, and the framework classes are associated with the Framework, then at the end of the process, the main bundle loads all of its jars. The problem is that the loading behavior is such that it doesn't restrict to your Resources folder, it loads ALL jars in the .woa. This means that it slurps up all the jars from your embedded frameworks also. This causes indeterminate load order of the classes, which is probably one of the most likely reasons people get the Session and Main problem. There are two fixes to this -- either you move your frameworks outside of the woa and modify your MacOSClasspath.txt to point to their new location, or you have to patch NSBundle. Hopefully we will have an acceptable workaround for this patching soon -- Q is working on some fanciness to make it possible to fix without shipping a decompiled NSBundle in Project Wonder. The combination of these two problems I believe explains the vast majority of these funky loading issues people run into ... The actual fix is submitted to Apple, too, so if they qualify and approve it, maybe these problems will go away in future WO's. ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: State of the Union
This is something I have been planning on implementing when using in- line WO tags. When the WO tags were simply name="wodBinding"> there was no way to differentiate what type of tag it was without parsing the WOD file as well, which is not part of the standard Third-Party Tags functionality of Dreamweaver. Now with the inline tag style, Dreamweaver's Third-Part Tags can now easily tell what type of tag it is (form, input, radio button, etc) and parse it accordingly - even assigning a different icon for it. All it takes is setting up a xml file for the WO tags and putting in one entry for each tag type. (and make the icon graphics...) To me, the trick with Dreamweaver is getting the project structure to match what Dreamweaver expects for images, css and such when the HTML file is inside a component. Dave On Oct 31, 2007, at 8:24 PM, Thomas wrote: Neil, I have in the past used Golive for this. It is very easy to define WO tags for Golive, plus the bindings they need. It also (unlike DreamWeaver) shows the WO tags as blocks that can be expanded and collapsed, and a separate binding inspector. (Mike, note that this is close to what I want!) With DreamWeaver, you only get an image to mark the start and finish of the block-- if you make the image yourself and define it in the appropriate XML file. However, Adobe have now sidlined Golive: after paying over a thousand dollars for CS3, they want many hundreds more to upgrade Golive. So I have resigned myself to migrating to DreamWeaver, which for some reason I never get around to using... Please see below for my (unofficial, perhaps wrong) answers about inline tags. Regards Thomas On 01/11/2007, at 10:59 AM, Neil MacLennan wrote: There is a common theme here, and it is still the one thing I am missing most from the WOLips Component Editor: the ability to see at a glance the layout of the component and all its elements, to click on an element to view all its bindings (defined or not) and edit these bindings in a separate area. Flex Builder does this beautifully. WO Builder does it well enough. Mike's latest outline view changes are awesome, much better in some ways than WO Builder, but it still doesn't give me the "what does it really look like" view. I've been taking a look at DreamWeaver's extensibility recently with a view to helping me with my "visual" WO development. I've recently moved to Eclipse/WOLips from XCode and am quite happy -- even with "hand-coding" my tags and wod definitions. Although I must say that if I hadn't had an upbringing on WOBuilder then it would have been *much* harder to get into the groove of hand building my HTML front end. I find myself mentally visualising what the page would have looked like in WOBuilder to help me make sure my hierarchies of webobject tags are OK! I wouldn't like to to come to this, new, for the first time! Anyway, my Eclipse WOA development tree lives inside a DreamWeaver site so that I can use DreamWeaver's templating ability to provide and update my page furniture as well as WYSIWYG for the non-WO bits (including tables w!). The trouble is, of course that DW ignores the WO tags and it doesn't help me visualise my page structure any better. I figure that whilst I might not get the drag'n'drop-ability (?) of WOBuilder if I can get DW to at least show my WO tags and their hierarchy then that's a great step forward and might help others who work with page designers rather than programmers. To cut a long story short (although I feel it's too late if you've got this far) DW is really quite extensible and it relatively straight-forward to add to its tag library (thereby enabling code completion, elementary validation etc within DW) and also to create placeholder graphics to show where WO tags are on the page in a similar way how WOBuilder did it. Further, although it might be beyond my capability if it needs C programming, one could create Tag editors within DW which might offer the library of WO elements to pick from and this would especially suit the inline style of .wo files rather than the .html/.wod duo. Here's my question then before I get too deep into this and find out it wasn't worthwhile: Because I'm a recent convert to Eclipse/WOLips I'm a bit new to the inline binding style (which would suit the plan with DW above) and don't use it myself yet, I'd like to understand a few things. 1) Can the inline binding style *completely* do away with the wod file? Yes. 2) Is this what Apple meant in their update notice for 5.4 when they said, "Combined Component Template Parser that reduces .wo components to single .html file" Yes. 3) Are inline bindings for 5.4 only, can I use them in 5.3 (Eclipse only I think, not Xcode), or are they Wonder only? You can use them for 5.4 (only inline or only .wod) with the "[thing.thing]" binding style, or using Wonder, correctly c
Re: State of the Union
On 31/10/2007, at 11:51 PM, Mike Schrag wrote: * My understanding is that JavaClient stuff is technically still there, but there's not very good tool support for it. NetBeans project file support for Entity Modeler would allow the combination of Entity Modeler plus the Swing designer tools from NetBeans, which would probably be a good platform to start from for that (Swing builders in Eclipse I think mostly suck still?). Interestingly we were using NetBeans + matisse for gui building up until some months ago, but switched over to Eclipse + WindowBuilder Pro which works well. But IDE portability is a good thing if needed. with regards, -- Lachlan Deck ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: State of the Union
Neil, I have in the past used Golive for this. It is very easy to define WO tags for Golive, plus the bindings they need. It also (unlike DreamWeaver) shows the WO tags as blocks that can be expanded and collapsed, and a separate binding inspector. (Mike, note that this is close to what I want!) With DreamWeaver, you only get an image to mark the start and finish of the block-- if you make the image yourself and define it in the appropriate XML file. However, Adobe have now sidlined Golive: after paying over a thousand dollars for CS3, they want many hundreds more to upgrade Golive. So I have resigned myself to migrating to DreamWeaver, which for some reason I never get around to using... Please see below for my (unofficial, perhaps wrong) answers about inline tags. Regards Thomas On 01/11/2007, at 10:59 AM, Neil MacLennan wrote: There is a common theme here, and it is still the one thing I am missing most from the WOLips Component Editor: the ability to see at a glance the layout of the component and all its elements, to click on an element to view all its bindings (defined or not) and edit these bindings in a separate area. Flex Builder does this beautifully. WO Builder does it well enough. Mike's latest outline view changes are awesome, much better in some ways than WO Builder, but it still doesn't give me the "what does it really look like" view. I've been taking a look at DreamWeaver's extensibility recently with a view to helping me with my "visual" WO development. I've recently moved to Eclipse/WOLips from XCode and am quite happy -- even with "hand-coding" my tags and wod definitions. Although I must say that if I hadn't had an upbringing on WOBuilder then it would have been *much* harder to get into the groove of hand building my HTML front end. I find myself mentally visualising what the page would have looked like in WOBuilder to help me make sure my hierarchies of webobject tags are OK! I wouldn't like to to come to this, new, for the first time! Anyway, my Eclipse WOA development tree lives inside a DreamWeaver site so that I can use DreamWeaver's templating ability to provide and update my page furniture as well as WYSIWYG for the non-WO bits (including tables w!). The trouble is, of course that DW ignores the WO tags and it doesn't help me visualise my page structure any better. I figure that whilst I might not get the drag'n'drop-ability (?) of WOBuilder if I can get DW to at least show my WO tags and their hierarchy then that's a great step forward and might help others who work with page designers rather than programmers. To cut a long story short (although I feel it's too late if you've got this far) DW is really quite extensible and it relatively straight-forward to add to its tag library (thereby enabling code completion, elementary validation etc within DW) and also to create placeholder graphics to show where WO tags are on the page in a similar way how WOBuilder did it. Further, although it might be beyond my capability if it needs C programming, one could create Tag editors within DW which might offer the library of WO elements to pick from and this would especially suit the inline style of .wo files rather than the .html/.wod duo. Here's my question then before I get too deep into this and find out it wasn't worthwhile: Because I'm a recent convert to Eclipse/WOLips I'm a bit new to the inline binding style (which would suit the plan with DW above) and don't use it myself yet, I'd like to understand a few things. 1) Can the inline binding style *completely* do away with the wod file? Yes. 2) Is this what Apple meant in their update notice for 5.4 when they said, "Combined Component Template Parser that reduces .wo components to single .html file" Yes. 3) Are inline bindings for 5.4 only, can I use them in 5.3 (Eclipse only I think, not Xcode), or are they Wonder only? You can use them for 5.4 (only inline or only .wod) with the "[thing.thing]" binding style, or using Wonder, correctly configured, using the "$thing.thing" style. In Wonder you can mix inline with .wod. 4) Anything else I should know that might help me here (or indeed if someone has done this before, although a google for "webobjects dreamweaver tag library" turned up little.) Being a grumpy person, 8^), I gave up on Dreamweaver when I realised that making a suitable tag library was beyond my competence (or my patience). Neil -- .neilmac ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40woomeranet.com.au This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be
Re: State of the Union
There is a common theme here, and it is still the one thing I am missing most from the WOLips Component Editor: the ability to see at a glance the layout of the component and all its elements, to click on an element to view all its bindings (defined or not) and edit these bindings in a separate area. Flex Builder does this beautifully. WO Builder does it well enough. Mike's latest outline view changes are awesome, much better in some ways than WO Builder, but it still doesn't give me the "what does it really look like" view. I've been taking a look at DreamWeaver's extensibility recently with a view to helping me with my "visual" WO development. I've recently moved to Eclipse/WOLips from XCode and am quite happy -- even with "hand-coding" my tags and wod definitions. Although I must say that if I hadn't had an upbringing on WOBuilder then it would have been *much* harder to get into the groove of hand building my HTML front end. I find myself mentally visualising what the page would have looked like in WOBuilder to help me make sure my hierarchies of webobject tags are OK! I wouldn't like to to come to this, new, for the first time! Anyway, my Eclipse WOA development tree lives inside a DreamWeaver site so that I can use DreamWeaver's templating ability to provide and update my page furniture as well as WYSIWYG for the non-WO bits (including tables w!). The trouble is, of course that DW ignores the WO tags and it doesn't help me visualise my page structure any better. I figure that whilst I might not get the drag'n'drop-ability (?) of WOBuilder if I can get DW to at least show my WO tags and their hierarchy then that's a great step forward and might help others who work with page designers rather than programmers. To cut a long story short (although I feel it's too late if you've got this far) DW is really quite extensible and it relatively straight- forward to add to its tag library (thereby enabling code completion, elementary validation etc within DW) and also to create placeholder graphics to show where WO tags are on the page in a similar way how WOBuilder did it. Further, although it might be beyond my capability if it needs C programming, one could create Tag editors within DW which might offer the library of WO elements to pick from and this would especially suit the inline style of .wo files rather than the .html/.wod duo. Here's my question then before I get too deep into this and find out it wasn't worthwhile: Because I'm a recent convert to Eclipse/WOLips I'm a bit new to the inline binding style (which would suit the plan with DW above) and don't use it myself yet, I'd like to understand a few things. 1) Can the inline binding style *completely* do away with the wod file? 2) Is this what Apple meant in their update notice for 5.4 when they said, "Combined Component Template Parser that reduces .wo components to single .html file" 3) Are inline bindings for 5.4 only, can I use them in 5.3 (Eclipse only I think, not Xcode), or are they Wonder only? 4) Anything else I should know that might help me here (or indeed if someone has done this before, although a google for "webobjects dreamweaver tag library" turned up little.) Neil -- .neilmac ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: State of the Union
Because I'm now the official grumpy customer standard, I think I'd better pull up my socks and provide some user feedback. A few months ago I offered to write a document that listed all the tasks when working with WO components, and how you would do them in WO Builder, WOLips Component Editor, and (just for completeness because I used to do this a lot) in Golive. The grand plan was that this could be a focus for communication between the user and developer communities, helping the developers to understand how we actually use the tools. Unfortunately, in addition to my usual project work, I got involved in a full-time on-site contract that has only just finished, and I have not had time to do it. And Mike Schrag has made it even harder by removing most of my "if only WOLips could do this" complaints. Ironically, while on site with the recent contract (a large comms system vendor, working on JSP and comms plumbing), I managed to convince one of the R&D managers that WebObjects would be useful for the entire organisation. The reason that it is ironic is that I was demonstrating WO 5.3 on his laptop, using XCode. He told me later that what blew him away and sold him on WO was WOBuilder, and how it seamlessly and visually built on the output of EOModeler. His user interface designers agreed. He was much less happy with WOLips and the obsolescence of the Apple tools. But I assured him WOLips was growing rapidly. In the end, the only way to make him completely happy was to demonstrate using WO web services as the back end and Flex as the front end. Once again everybody involved got really excited because they could use a GUI visual editor to develop the user interface, and the GUI designers could work pretty much independently of the application developers. There is a common theme here, and it is still the one thing I am missing most from the WOLips Component Editor: the ability to see at a glance the layout of the component and all its elements, to click on an element to view all its bindings (defined or not) and edit these bindings in a separate area. Flex Builder does this beautifully. WO Builder does it well enough. Mike's latest outline view changes are awesome, much better in some ways than WO Builder, but it still doesn't give me the "what does it really look like" view. Component Editor's Preview pane may do a lot of what I want (except tables), but unfortunately almost every time I click the "Preview" tab, Eclipse hangs on 100% CPU use. Mike has already identified the lack of table display, and I believe he knows all of this stuff already. But as a grumpy customer standard it's my duty to express it. 8^) Please note that I am NOT asking for a WebKit-rendered preview of what the final page will look like. I use CSS heavily, many of my components are used with many different CSS "skins," and I would rather avoid that complication. However, I really miss tables. There are times when no amount of outlining will help. For example, when editing a table showing a list of products, one attribute per column, with WOStrings for the header and rows, and trying to work out exactly which corresponds to the that describes it. This is very hard in any WOLips view, and trivially easy on WO Builder. Also inserting rows (not too hard in WOLips) and columns (very hard in WOLips) is trivially easy in WO Builder. Now assuming I had tables in a preview mode that didn't hang Eclipse, (not being narky, Mike, just telling how it is), there is still one important thing missing: the ability to change the bindings while in preview mode. So here's my wish list: - add a bindings inspector that shows all possible bindings of the currently selected component, with auto-complete when typing values; - make a combination of the preview and outline view that allows you to select a component so you can view/edit its bindings - add table support. Now a local cultural reference: "Tell 'im 'e's dreamin'!" (extra points for those who recognise the reference). In my mind I had a long list of things to complain about, but that darned Mike Schrag has chewed that list right up! And as the official standard grumpy customer, I would like to complain about how Mike has so thoroughly reduced my list of complaints. Regards Thomas On 31/10/2007, at 11:51 PM, Mike Schrag wrote: * WebObjects Builder is dead and gone. Component Editor replaces it. This is the #1 point of contention, I believe, as Entity Modeler is a fairly complete replacement for EOModeler. Component Editor does not provide the equivalent of the quasi-preview mode (the thing that can do the table editing with binding wiring). It does provide, in recent builds, component previews that are very similar (I think more useful, IMNSHO :) ) to WOB's, extensive support for completion, and there is a new bindings editor coming that i
Re: State of the Union
Can anyone give a true state of the union write up as to where we are with tools and the future based up Leopard now released, the WWDC over with ( and hopefully any NDAs not infringed ) and the involvement of WONDER etc... It would be good to have a coherent vision of what we have and where we are going Here's my notable bullet point list: * WebObjects is very much alive. WebObjects 5.4 is the first step in many years of Apple actually trying to move the platform forward, and more will come. * EOModeler is dead and gone. Entity Modeler (from the WOLips project) replaces it. iTunes Store has also funded us to develop a .app variant of Entity Modeler that you can run outside of Eclipse. In the current builds, Entity Modeler.app is able to read IDEA and Eclipse project files to determine model dependencies. NetBeans project file support is likely also coming. * WebObjects Builder is dead and gone. Component Editor replaces it. This is the #1 point of contention, I believe, as Entity Modeler is a fairly complete replacement for EOModeler. Component Editor does not provide the equivalent of the quasi-preview mode (the thing that can do the table editing with binding wiring). It does provide, in recent builds, component previews that are very similar (I think more useful, IMNSHO :) ) to WOB's, extensive support for completion, and there is a new bindings editor coming that is essentially based on the bindings inspector panel from WOB (for people who don't want to think about it, the intent is that this can replace the WOD Editor view). For what I'm doing, this is the majority of my focus at the moment. Well, "easier-to-use" in general has been my main focus for the past few weeks. I've been really trying to go through the UI's and tighten things up (the new Entity Modeler error dialog is a good example of this). I really want to get the tools to a place where WOB people aren't totally turned off. I don't know how far that will go at the moment. Thomas has been my grumpy customer benchmark up until now, but he's been unusually happy recently. As luck would have it, I think I have found my new grumpy customer benchmark. * RuleEditor is dead and gone. Rule Modeler replaces it. Again, not mine :), but it's in Project Wonder, and from what I hear, it's just better in every respect. I don't think anyone can be upset about this one. * Xcode isn't dead, but WebObjects support in Xcode mostly is. The build system required to build WO projects is still there. So if you have existing Xcode projects, they will continue to build. The WO project templates are gone, but like Ray said, you could pretty easily bring these back. If Entity Modeler gained support for reading project/framework dependencies from .xcodeproj files (which I had said I will not do, but if there's some overwhelming support for this, I might reconsider ... or if someone else wants to donate that, I will merge it in) you could actually use Entity Modeler completely as an EOM replacement. WOB is the big missing piece for Xcodies. There is BASICALLY no way to make Component Editor a standalone app (it requires too much in terms of Java project dependencies). Given that it seems to me that the people most likely to stick with Xcode are also the people who are probably most upset about the loss of WOB, this presents an unfortunate situation. The way, truth, and light from Apple is WOLips and Eclipse, though. * My understanding is that JavaClient stuff is technically still there, but there's not very good tool support for it. NetBeans project file support for Entity Modeler would allow the combination of Entity Modeler plus the Swing designer tools from NetBeans, which would probably be a good platform to start from for that (Swing builders in Eclipse I think mostly suck still?). * JavaMonitor and wotaskd are open sourced in Leopard. I don't know if this means that there are replacements coming in future releases and their value is therefore lessened, or if it is just an act of goodwill from Apple. Either way it's great. * EOGenerator, EOReporter, and DBEdit no longer work in Leopard. Apple has provided a replacement to EOGenerator in the form of JavaEOGenerator. It will be released as an open source example on the Apple site within a few weeks. In the meantime, Apple has been gracious enough to slide permission under the table for us to do release of it for early adopters (see my previous post). The template format changes (which is to be expected -- EOGenerator was using a very old Obj-C library for the template system), but other than that it should be fully compatible with EOGenerator. * As far as the involvement of Wonder in all of this, for the most part, the same relationshi
State of the Union
Can anyone give a true state of the union write up as to where we are with tools and the future based up Leopard now released, the WWDC over with ( and hopefully any NDAs not infringed ) and the involvement of WONDER etc... It would be good to have a coherent vision of what we have and where we are going Gino ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
