MulleEOF

From EOFWiki

Jump to: navigation, search

Contents

[edit] Description

image:Blue-Mulle-Titmouse.gif

MulleEOF is an API compatible and binary compatible replacement of EOF 4.5. You can replace the original Apple frameworks with MulleEOF and your applications will work just as before. You don't need to change your source code, your EOModels or your NIBs.

MulleEOF internally has a different structure than the familiar EOControl, EOAccess, EOInterface triple.

Image:MulleEOFLayers.png


Note: MulleEOModellingSupport is missing from the picture as it didn't fit well. It would occupy the same space as MulleEODatabaseStore

[edit] Components

MulleEOF consists of

and as EOF needs adaptors to connect to the database, it also knows a variety of EOAdaptor frameworks

for compatibility with other EOF products there also


A look at the classes and their interrelationships:

Image:EOFClassesLayered.png

Download the PDF to look at it in detail.

[edit] Articles

Articles about EOAccess

Articles about EOControl

Articles about EOInterface

Some of these articles are not part of this Wiki and therefore also not part of the CC license.

[edit] Documentation

[edit] Tweaks

[edit] Build problems

[edit] Runtime Exceptions

Exceptions that are raised by MulleEOF itself or that occur frequently when developing MulleEOF applications.

[edit] Runtime Warnings

Warnings issued by MulleEOF at runtime, and how they should be interpreted.

[edit] Runtime Output (except warnings and exceptions)

Informational output from MulleEOF and what it means.

[edit] User Application Problems

[edit] Other Topics

[edit] See also


Documentation for EOF is available from Apple on the developer site.

Also some of these links may be helpful, as EOF became a part of WebObjects at some point in history

Most of these links are not part of this Wiki and therefore also not part of the CC license.

[edit] Ideas for future development

  • +[EOClassDescription classDescriptionForClass:] could employ a naming scheme to find the proper classDescription at runtime. Foo -> FooClassDescription.
  • Could use runtime introspection to provide default EOF classDescriptions for lazy classes. Then classes would rather implement "negative" methods, to remove instance variables from EOF handling.
  • break EOEditingContext down into constituent classes for edit tracking, globalID management and maybe make it a class hierarchy also. Could also use a default naming scheme to separate attributes from relationships and toMany relationships
  • fix the glaring +formatValue:forAttribute: bug in EOSQLExpression
  • as an alternative define an EOObjectStore @protocol and an EOEditingContext @protocol. The latter only does change tracking. The former is responsible for saving and fetching.
  • change EOObjectStore to become independent of EOEditingContext. Instead define a protocol, that supplies the needed methods for ObjectStore dealings. Then EOObjectStore and EOEditingContext can each be their own framework. Methods needed are (glanced at MulleEODatabaseStore):
    • recordObject:globalID:
    • insertedObjects, deletedObjects, updatedObjects
    • objectForGlobalID:
    • insertObject: (for propagate PK hack)
    • rootObjectStore (for batching hack, sigh, should get rid of this)
    • _gidsWithoutObjects (internal methods, not a problem)
  • enhance the EOEnterpriseObject protocol, so that EOEditingContext is truely independent of EOClassDescription (now it's used in one case)
  • (request) JOPE like fetchSpecifications to send to the adaptor layer like
<fetch name="moderatorWorkloadFetch"
flags="readonly,rawrows"
>
<sql><![CDATA[select)s assignee, COUNT(*) FROM ticket AS BASE WHERE
BASE.status < 5 GROUP BY BASE.assignee ORDER BY BASE.count DESC]]></sql>
</fetch>
Probably to be implemented with a EOSQLFetchSpecification or just custom hints for the adaptor ??
  • how to do cascade delete in the client on multiple entities in a database
  • add one or two new operators maybe ~ (Tilde) for qualifiers: a ~ b and ~~. Meaning a like b and a caseinsensitive b, except for attributes that aren't numbers where it will revert to equal. As an alternative specify like/caseinsentivelike to revert to equal for numbers too... Dilemma: would it make sense to check to_string( a) like '1%' ?

[edit] Stupid Ideas (learning from mistakes)

[edit] History

Nothing yet.

[edit] License

MulleEOF is a mixture of Open Source, free binary releases and commercial parts.

[edit] Project pages

[edit] Related Projects and other Resources

Personal tools