Class Abstraction for Modularity

In order to make this flexible, I've switched from plugins to modular core objects.

I went back to my original goal which was to make a limited core application with few features, then let the user add all their fun custom stuff in the form of actual scripts that will be managed by the project. I still wanted people to be able to use their own authentication methods and database methods, which I was very confused about.

Then, simon w gave some great ideas in a bit-tech forum thread about class abstraction.

I basically implemented his recommendation for the authentication and database portions of the Shoehorn project. Now, all someone has to do is write their own extension to my abstract class, then set the config variables to use the proper class. (They don't have to include any files or anything, they just have to create a new class with the proper naming technique and save the file with the proper name in the proper place.)

Head over to http://shoehorn.googlecode.com and browse the source tree to see what I'm talking about. Especially shoehorn_auth.class.php and shoehorn_auth_ldap.class.php which is my only good example of this so far. (well, the database classes are ok as well, but I'm not done with those yet, so they aren't as impressive)

Ideas on making this modular

I'm trying to come up with ways to make this tool as modular as possible. My goal is to throw a "module" into a folder, then be able to use it.

What I may do is simply define some default variables that must exist in a specific file for each module to define things such as:

• name
• version
• last release date (I can't stand not knowing how old my module is)
• official website
• current version url (for determining if there is a new version of the plugin)

The only thing I'm trying to figure out now is how to add "hooks" into my parent class. I want to have as few core methods as possible because I don't want to add any unneccessary "features". I want user authentication in my wiki, but someone else might not, or they may want an entirely different type of authentication. (maybe they want to use a login script based on a hardware device, or an existing authentication system, while I want to use LDAP...)

I'll start poking around other apps to see how they do it. (Such as wordpress and similar)

Then I'll just have to decide where to hook in with my authentication module...

Intro to the podcast

Now I'm just testing out the podcasting feature (enclosure link feature) of blogger.com to see if I can integrate a podcast into the shoehorn project! Let me know what you think!

Welcome to the Shoehorn Project Blog!

I have just started my third open source project in the open source community, but this will be the first one I actively develop and update. (My past two were mostly completed but never released due to neglect and laziness.)

On this blog I will comment what I'm thinking, why I'm thinking it, and possibly how much coffee I've had each day.

I hope to post updates to the blog once every few days, and updates to the initial code a couple of times per week.

You can find all of the code, the wiki, and real information over at the project homepage.


I am allowing comments for now, but too much abuse may just make me close the comment door altogether due once again to my laziness. (I'd rather spend my time coding instead of moderating.)

Coming up tomorrow: what the shoehorn project actually is.