Library API

After spending hours with Taxonomy trying to use it to construct a single tiered Library, The problem was that the module of taxonomy was too specific to what it does. I also saw that with in my code, I was running multiple select statements that were unnecessary. In addition my library was small, and I feared using a growing database full of taxonomy data would hinder the performance of my script. Simply put, Taxonomy was to high level for what I needed, and didn't provide the low level functionality and flexibility that I wanted.

I needed to write my own library routine, and modifying taxonomy was not an option. I wasn't using this to classify content, but as a simple place holder for strings. I then went off to write taxonomy 2.0, but found the task was too large on its own to complete in a reasonable time.

I came up with the idea to build a low level api that would be flexible enough to hold my data, and found that it was easy to include functionality that would be useful for other applications, such as taxonomy, categories, dictionaries, Thesaurus, or to provide other module developers the frame work to include the library within administration functions or end user applications.

The framework I came up with was a 3 class system, Library, Terms, and Term.

1. Library would contain basic information on the details of the data set that would enable it for most applications. However I realize that this module in itself was not going to provide the necessary specialized data for taxonomy. I therefor set it up to be inherited by other applications, and expanded using basic OOP practices. In addition, the flexibility of the OOP structure could provide this extra data as the application developer found necessary, or could be replaced entirely with its own logic and criteria.
   For example Taxonomy may implement my library by adding node id (or content_ID) based features. I use the term content_ID, because comments, user profile, and other applications are not included within the node based system. This must also be paired up with a content_type field, that could identify the difference. Content_ID then could be User_ID or Comment_ID. As you can see this is a flexible system. Lastly I added a arbitrary field for providing additional data, that an application developer could use to provide any last relational data that the above doesn't cover.
2. Terms provides a collection of individual terms and functions to load, save, delete, create.
3. Each Terms can be assigned its own table, and can be produced with an argument in the create terms process. My Library class stores this table information. Therefor each developer can utilize his own table structure for the library, and not be lumped with the same data of hundreds of other terms. This is optional functionality of course.
4. The terms class will provide the overall mass loading, saving, deleting, etc functionality that will be necessary. It will keep a collection of terms on load, and can be stored in for small libraries.
5. Term will provide individual string functions for updating and saving single field terms. Inserts, Selects, Deletes, and Updates are provided at this level.

As you can see this provides the functionality needed for the developer to quickly add lists of terms for his project. But this does not limit the compatibility and special needs of certain applications. Take the Thesaurus or Dictionary example. An added table would be needed in each case to build the relations of terms together. When we deal with words, it is a mistake to assume that a parent child relationship could provide us with the flexibility needed in linking values. Words simply don't have parents, instead they are simply associated with each other. Parents and Children implies ownership, yet no single word is the owner of another word, and in multiple languages, including English, a word can have multiple separate associations. Therefor this three tiered approach allows for these specific needs by avoiding, inheriting, overriding the base functionality of any of the 3 tiers! Going back to the dictionary terms, we could build one link table associated with the many different associations a dictionary possesses. Even different definitions for each word. Another link table can then provide the Thesaurus capability!

A potential benefit of this structure is predefined form and display abilities that can be shared among multiple applications. Example: Developer A builds a block that will benefit Developer B. Because of the low level nature of this API, sharing this code becomes easier, and the deployment of applications will be accelerated. Also we must take into account that each application will utilize this differently.

So is this concept a dream, waiting for some developer to write the code? NO! The library classes in its base form is almost finished, and will be implemented in another module I am writing! What will remain is the utilization and expansion of the library to add more display routines and the implementation of this basic API into other aspects of the system.

I can (and will) write the field displays and theme functions for the applications I am writing this for, but to expand on this and to create additional forms and displays, I will need the development community as a whole to contribute the routines they write when they implement this within their individual applications.

Problems with current systems that can be seen, where this can be beneficial is in the taxonomy application where a Many to Many association can be deployed rather then the 1 to many relationships that currently exist. The localization routine is indexed by words and phrases, the potential downside of this is in languages that may have multiple words that fundimentally mean the same thing but that are used differently. By creating an ID based system within this, translators can employ this ability easier. Categories (and breadcrumbs) is a parent child relationship, that is hierarchical in nature, and can also be stored using my functions.

Why would you re-write your current code to utilize my framework? because the documentation of the API will be complete, end customers (the developers of the website) can use my lower level functions to modify and control the terms and their definitions, and the class structure provides an easy way for one module or function to pass along the object without re-creating the library on each call, greatly reducing the number of queries on the database. Lastly a generalized unification of code creates reliability and security by provided a single source to maintain and upgrade, thus effecting its children with the new abilities.

What I need to know is if this is worth my time to submit, and if interest is established using such a system. If its not adopted, then the use of it is null and void, and I will simply publish it with my unrelated module. I am looking for feedback on this idea!

Thanks
Mike