• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Help Please: Problem with Insert in Chapter 10 of Web Applications Tutorial
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help Please: Problem with Insert in Chapter 10 of Web Applications Tutorial


  • Subject: Re: Help Please: Problem with Insert in Chapter 10 of Web Applications Tutorial
  • From: Chuck Hill <email@hidden>
  • Date: Fri, 10 Oct 2003 15:57:37 -0700
  • Organization: Global Village Consulting, Inc.

Hi Art,

Art Isbell wrote:

On Friday, October 10, 2003, at 07:51  AM, Chuck Hill wrote:

This is a perfect example why you should always use EOPrototypes. They make such changes nearly painless.

One cause of pain when using EOPrototypes is that "EOPrototypes" is an entity name. Like other entity names, it must be unique in any EOModelGroup (i.e., in all eomodels loaded into a process). So if you use or might use multiple eomodels in an application, you cannot have an EOPrototypes entity in each model.


Correct.  Also, EOJDBCPrototypes is probably the better name to use.

I think I have run into other pains using EOPrototypes as well. I can't recall the details, but I think what happened was that I had an eomodel that used EOPrototypes defined in a different eomodel. Maybe I then tried to use this eomodel in an app without the eomodel that included EOPrototypes. I think this resulted in attributes not being completely defined causing run-time exceptions.

Because of these pains, I quit using EOPrototypes, but maybe I didn't try hard enough :-)
>
:-)

Maybe a workaround for these problems would be to define an eomodel with a single entity, EOPrototypes. This eomodel would be in a custom framework loaded by every custom application. Anyone tried this? Any other workarounds for these problems?

Yes, that is what I do. In fact, that EOModel also has EOFrontBasePrototypes, EOOpenBasePrototypes, EOOraclePrototypes, etc. At runtime I have code that copies the values from the EO<DB Name>Prototypes to EOJDBCPrototypes based on a config setting. For EOModeler this has no effect and you need to manually switch EOJDBCPrototypes if you want to generate SQL or browse data.

Jonathan Rochkind (and others) have previously posted code to do this on the fly switching. It is probably also on WODev or WOCode, I know I've seen it recently somewhere.

I've worked with prototypes and without them. I'll never work without them again!

Chuck


--

Chuck Hill                                 email@hidden
Global Village Consulting Inc.             http://www.global-village.net

Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Help Please: Problem with Insert in Chapter 10 of Web Applications Tutorial (From: Art Isbell <email@hidden>)

  • Prev by Date: Re: WebObjects and Panther
  • Next by Date: Grumbling McCreyekes
  • Previous by thread: Re: Help Please: Problem with Insert in Chapter 10 of Web Applications Tutorial
  • Next by thread: Re: Help Please: Problem with Insert in Chapter 10 of Web Applications Tutorial
  • Index(es):
    • Date
    • Thread