• 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: Framework EOModel Question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Framework EOModel Question


  • Subject: Re: Framework EOModel Question
  • From: Chuck Hill <email@hidden>
  • Date: Thu, 4 Aug 2005 09:10:45 -0700

Lachlan,

On Aug 3, 2005, at 11:15 PM, LD wrote:

That's helpful... but how do you create a framework that will make sure a specific db plugin framework, for example, is utilised when included in a project (that should be agnostic about the underlying db)?


Simple, you don't. :-) The framework is db agnostic. The application (or classpath at least) can't be. Loading prototypes and the connection dictionary at runtime will allow your framework and application to run with multiple databases. But at runtime you either have to ensure the correct plugin is on the classpath or load them all. Which amounts to the same thing, I guess. Frameworks can't control the application's classapath beyond the jar files contained in the framework. You could, I suppose, embed the jar files for all possible plugins in your framework. Imagine how much fun keeping that system updated will be!



The framework isn't db agnostic (currently)

Tsk Tsk ;-)


because the EOModels in the framework are currently tied to postgres specific column attribute types. Any tips on making the models db agnostic?

EOPrototypes, as Kieran pointed out. A model without prototypes is, um, dumb. A reusable framework without prototypes is not reusable. See Practical WebObjects pages 45 - 55 for a discussion of this and code. There is some very superficial discussion in the EOModeler docs.


I'm utilising the postgres 'serial' type for auto-incrementing primary keys...

I can't see how EOF is going to be happy about that. To promote reusability you should avoid non standard, DB specific features.



then there's timestamp types and so on...

Those are usually pretty standard.

Chuck

--
Practical WebObjects - a book for intermediate WebObjects developers who want to increase their overall knowledge of WebObjects, or those who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects




_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Framework EOModel Question
      • From: LD <email@hidden>
References: 
 >Re: Framework EOModel Question (From: LD <email@hidden>)
 >Re: Framework EOModel Question (From: Chuck Hill <email@hidden>)
 >Re: Framework EOModel Question (From: LD <email@hidden>)

  • Prev by Date: Re: Child Editing Contexts -- locking/unlocking
  • Next by Date: Re: Reusable Component Tricks...
  • Previous by thread: Re: Framework EOModel Question
  • Next by thread: Re: Framework EOModel Question
  • Index(es):
    • Date
    • Thread