From: Benjamin J D. <bj...@po...> - 2004-08-27 00:34:26
|
Friends, This is a minor aggravation that is easily worked around but could defeat the purpose of having this framework in the first place. For Postgresql and MySQL, all prototypes do not allow null. But for Oracle and Frontbase, they do allow null. Is there a reason for this difference? Can we commit a reconciliation? Cheers, Benjamin J Doherty Chicago, U.S.A. |
From: Anjo K. <kr...@lo...> - 2004-08-27 07:00:48
|
Am 27.08.2004 um 02:34 schrieb Benjamin J Doherty: > This is a minor aggravation that is easily worked around but could > defeat the purpose of having this framework in the first place. For > Postgresql and MySQL, all prototypes do not allow null. But for > Oracle and Frontbase, they do allow null. Is there a reason for this > difference? Can we commit a reconciliation? They all should *not* allow NULL. I fixed this for Mysql as this was the DB I used and the Postgres version is AFAIK a copy of it. The reason is that the allowsNull property is not copied to the resulting attribute when the app is run but EOModeler displays it as such - so all your attributes end up with allowsNull unset. Cheers, Anjo |
From: David T. <dav...@cl...> - 2004-08-27 07:30:35
|
Hi, i can not recommend to use the ERPrototypes anymore. They simply make too much problems in my point of view. You cannot open a model directly from Eclipse nor from XCode, you must open it from ProjectBuilder (afaik) which is a pain. You cannot have EOModels in the application bundle and you always must ensure that the ERPrototypes bundle (framework...) is loaded before every other framework with an EOModel. All these things forced us to not use EOModels anymore. regards, David Am 27.08.2004 um 02:34 schrieb Benjamin J Doherty: > Friends, > > This is a minor aggravation that is easily worked around but could > defeat the purpose of having this framework in the first place. For > Postgresql and MySQL, all prototypes do not allow null. But for > Oracle and Frontbase, they do allow null. Is there a reason for this > difference? Can we commit a reconciliation? > > Cheers, > > > Benjamin J Doherty > Chicago, U.S.A. > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Wonder-disc mailing list > Won...@li... > https://lists.sourceforge.net/lists/listinfo/wonder-disc > |
From: Ashley A. <mrh...@ma...> - 2004-08-27 09:12:21
|
Hi David (and List Members) On 27/08/2004, at 3:30 PM, David Teran wrote: > i can not recommend to use the ERPrototypes anymore. They simply make > too much problems in my point of view. Thank you for sharing your opinion / experience - it is valued (by me at least). > You cannot open a model directly from Eclipse nor from XCode, you must > open it from ProjectBuilder (afaik) which is a pain. Opening models with EOPrototypes in Eclipse works for me, and although I done it in Xcode 1.5, it did work with 1.2. Are others finding this too? > You cannot have EOModels in the application bundle Doesn't it generally make more sense to have them in frameworks anyway? > and you always must ensure that the ERPrototypes bundle (framework...) > is loaded before every other framework with an EOModel. This one sounds significant but I have not encountered it because I usually only have two eomodels in the business logic framework (the EOPrototypes and the actual EOMOdel. > All these things forced us to not use EOModels anymore. Thanks again for the heads up. Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com |
From: David T. <dav...@cl...> - 2004-08-27 09:17:51
|
> Opening models with EOPrototypes in Eclipse works for me, and although > I done it in Xcode 1.5, it did work with 1.2. Are others finding this > too? > ? You can open an EOModel which uses ERPrototypes directly from within Eclipse and all columns show up correctly ? Is this only when xcode is open or can xcode be closed, too? regards David |
From: Ashley A. <mrh...@ma...> - 2004-08-27 10:16:40
|
On 27/08/2004, at 5:17 PM, David Teran wrote: >> Opening models with EOPrototypes in Eclipse works for me, and >> although I done it in Xcode 1.5, it did work with 1.2. Are others >> finding this too? >> > ? You can open an EOModel which uses ERPrototypes directly from within > Eclipse and all columns show up correctly ? Is this only when xcode is > open or can xcode be closed, too? Yes, I can open and EOModel which uses EOPrototypes (these are my own prototypes but they are based on the ERPrototypes model) from within Eclipse and all the columns show up correctly without Xcode open. I, however, have chosen to use the "framework jiggle" (as I call it) described here: <http://www.objectstyle.org/woproject/wolips.html> that relies on the PB.project file and the old form of inter-application communication. It does have some consequences: 1. I don't believe you can create EOModels in EOModeller, but that is not a big problem because WOLips has a wizard for creating them. 2. Xcode can no longer communication with WOBuilder and EOModeller, but that is not a problem since I use Eclipse, and anyway it is easy to swap from one to the other (with a simple script). 3. EOModels must be in the top of the project directory (they cannot be in subdirectories) but this is not a real problem (it is a limitation of the old PB.project projects). 4. Application and Session cannot be in packages but this is not a problem since they can still extend packaged classes, or you can create another Application and Session that extend your packaged Application and Session. It is all working quite fine for me at present (I think ;-) Hope that helps. Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com |
From: Anjo K. <kr...@lo...> - 2004-08-27 10:17:16
|
Am 27.08.2004 um 11:11 schrieb Ashley Aitken: >> You cannot open a model directly from Eclipse nor from XCode, you >> must open it from ProjectBuilder (afaik) which is a pain. > > Opening models with EOPrototypes in Eclipse works for me, and although > I done it in Xcode 1.5, it did work with 1.2. Are others finding this > too? I think the trick is either to use not use PBX/XCode at all and instead the PB.project files or to have XCode running. As this is the same with components, it's not that much of a requirement. But still, it is a very shaky setup... >> and you always must ensure that the ERPrototypes bundle >> (framework...) is loaded before every other framework with an >> EOModel. > > This one sounds significant but I have not encountered it because I > usually only have two eomodels in the business logic framework (the > EOPrototypes and the actual EOMOdel. You can control the load order either with the XCode settings, your ant files and your launch settings in WOLips. You have to remember needing to do it, though. Having said that, we use our own "prototype" stuff which is much more capable that EOPrototypes, but I still have legacy projects and use it there. It'd be nice if Apple got around fixing EOM, though Cheers, Anjo |
From: Benjamin J D. <bj...@po...> - 2004-08-28 01:12:59
|
On Aug 27, 2004, at 5:17 AM, Anjo Krank wrote: > I think the trick is either to use not use PBX/XCode at all and > instead the PB.project files or to have XCode running. As this is the > same with components, it's not that much of a requirement. But still, > it is a very shaky setup... > > You can control the load order either with the XCode settings, your > ant files and your launch settings in WOLips. You have to remember > needing to do it, though. > > Having said that, we use our own "prototype" stuff which is much more > capable that EOPrototypes, but I still have legacy projects and use it > there. It'd be nice if Apple got around fixing EOM, though > <pouting> Fine! I tried the Postgresql.framekwork from Project Wonder, and that never worked for me... it never generated the sequences on the fly as it said it would and it would always give me a primary key error. Now I use MySQL, which makes me feel very immature. Oh how I miss my update-able views! Then I tried ERPrototypes.framework, which I'm now told is inadvisable. (I'm very susceptible to persuasion by experts.) Because ERPrototypes.framework depended on ERExtensions, I tried using that. I actually liked it a lot! It gave me lots of feedback about what foreign keys were set as NOT NULL but their relationships weren't mandatory. That's very helpful! It would do its best to avoid null pointer exceptions with newly created entities so that I could defer referential integrity until EOF generated primary keys for me in my new entity instances. But It doesn't work for 5.2.2. It crashes immediately because it can't find CLI arguments or something. I don't really know. I just know it works under 5.2.3, but Java Client applications DO NOT WORK under 5.2.3. So I gave up on that yesterday. I had hoped to move up to using ERCalendar and other things I could wrap my brain around and that seemed fairly simple to start with. But now I give up. It seems like not even Project Wonder's developers want me to use Project Wonder! When I think about it, I was getting along just fine without Project Wonder! Does EVERYTHING require that I use WOLips to develop? I don't mind using ant as long as the commands are fed to me in a clear manner. I hope it has a better track record than Project Wonder. See, I'm not a Java developer. Eclipse is not a familiar environment. Xcode seems like home. And I'm a one-man WebObjects developer, so I don't need cross-platform development. </pouting> I'm not angry or upset with anyone... except maybe Apple... damn I hate Apple Computer, Inc. THEY should be paying everyone US to use their WebObjects. Benjamin J Doherty Chicago, U.S.A. |
From: Benjamin J D. <bj...@po...> - 2004-08-27 11:08:40
|
On Aug 27, 2004, at 2:30 AM, David Teran wrote: > i can not recommend to use the ERPrototypes anymore. They simply make > too much problems in my point of view. You cannot open a model > directly from Eclipse nor from XCode, you must open it from > ProjectBuilder (afaik) which is a pain. You cannot have EOModels in > the application bundle and you always must ensure that the > ERPrototypes bundle (framework...) is loaded before every other > framework with an EOModel. All these things forced us to not use > EOModels anymore. Well that's too bad... I mean I can set up my own prototypes, but it was nice to have something semi-official to use that fit the bill and that solved the problems of when to use BLOB and how to use BOOLEAN values. And the funny thing is that I DID get it to work in xcode. I just replaced the EOPrototype.plist file with the one for my database on my development machine. I presume i could just have set the erprototype.* properties in my application on my deployment server. Benjamin J Doherty Chicago, U.S.A. |