Saturday, November 22, 2008

Arrogance and Code Hosting

Arrogance: I'm going to write like I actually have an audience here.

Code hosting: I'd been unsure of how to go about posting the code to my projects, trying sites.google.com, which can host files within a wiki-type application, to Drop.IO, again with file hosting, though they both suffer from making it difficult to push large projects to them. I had to tar.gz them to keep them contained, and that's just not how you do this kind of thing.

And then Ars Technica posts a guide to setting up an account and repository on GitHub. I Already put Simple Extension there and updated the post here to reflect the new code location and changed the drop.io link to point to github. As I work on the other projects, they'll get repositories too.

Tuesday, November 11, 2008

Shimmie Extension - User Permissions

This is a three-in-one.

User Permissions manages a more complex form of user permissions than can easily be done in Board Config. Basically, in default Shimmie you have three de-facto user groups: Admin, Registered, and Anonymous. Problem is, admin has access to everything, so if you wanted to let some registered users help police images and other user content, you'd have to trust them not to screw you with their admin access, up to and including de-admining your user.

Anyway, it started as an all-in-one that established user groups, default permissions, group-level permissions, and user-specific permissions. This got unwieldy very fast, especially since the user groups part was basically an extension in itself. So I split it in four pieces: User Groups, Global Permissions, Group Permissions, and User Permissions. As posted earlier, User Groups managed groups of users.

Global Permissions was basically a store of all the registered permissions, name, description, and default value.

Group Permissions built on top of Global, if there's a setting for the group level, it uses that, or falls back to global.

User Permissions builds on top of Group. Like Group, it falls back on groups the user is in if user level is unset (multiple settings for one permission are ORed together,) or to global if there are no groups with that permission set.

These were going to be separate extensions, with group and user being agnostic of each other (though depending on global.) Unfortunately, I could not figure out how I'd go about untangling the levels from each other, so I merged the three back together, partially. It has three separate extension definitions, each handling one level, and I could drop the need to have them able to work separately from each other.

So an extension can use this by registering options by hooking the PermissionRegisteringEvent and calling $event->register(String $key, String $name, String $description, Boolean $default), then later access the permissions applied to a user with Permission::user(User $user, String $key).

It's not as clean as the Config object, I admit. I want to have access to it through the User object since it would look like User::permission(String $key), but I also didn't want to require a code patch for core files. I was able to skip requiring the Config and Database objects from being passed in to Permission::user() by cheating and importing globals into the function.

Works well regardless, though it suffers from a bit of disuse. So far there are only 2 extensions that use it.

GitHub Repository
Commit at time of post: 14735d34
Dependencies: Simple Extension, User Groups

Shimmie Extension - User Groups

Split off another extension I was writing, which needed a method to group user to allow it to act on many users at once.

User Groups does that, and later extensions can add additional features to them, such as chat, forums or news. If they do become more social contructs like that, I'll have to add a few features to facilitate that, since right now only admin can create groups and add users to them.

Probably some manner of group ownership and a few settings the owners can change regarding membership will be next.

Anyway, the initial point was accomplished: groups of users.

GitHub Repository
Commit at time of post: e81093d3
Dependencies: Simple Extension

Thursday, November 06, 2008

Shimmie Extension - Simple Extension

Got tired of defining Event::receive_event when making a new extension, and got tired of starting to code in the if statements, "Oh, it's just a little bit of code..." and then an hour later: "Crud. It's like, three pages long and 5 tabs deep now," and spend the next few days refactoring code.

Anyway, there's the inspiration. A few weeks ago I had thought that it would be easier to have an XML file control the event hooking, like WoW does, but that got kind of silly when I realized that the control would be split across the XML and extension code, and I'd have to figure out the XML DOM. Then I realized that the most basic use of the thing would essentially be exactly the same across extensions, I dropped it.

So today, I decided it wouldn't be too much of a loss if I defined the function once in such a manner that it gets the class type of the incoming event, looks for a function of the same name in the extension class, and calls that (passing the event along, of course.)

So there. Simple Extension creates another abstract of the Extension class, and does just that, as well as make the theme object, and so far it seems to work pretty well.

To use, install by uncompressing the archive into contrib/ and activate by creating a symlink in ext/ to contrib/!simple_extension or by using the Extension Manager. Until a dependency resolution system is created, removing the exclamation mark from


After that, make a new extension, but instead of "class hello_world implements Extension" use "class hello_world extends SimpleExtension" and then write methods like this to use events:

public function PageRequestEvent(Event $event) {
// PageRequestEvent code here
}


GitHub repository
Commit at time of post: 13434a2c
Dependencies: util.inc.patch (Ticket #360) to allow get_theme_object to skip non-existing base themes. Patch incorporated into core.

Shimmie

A while back I came across an open source php web application called Shimmie that stores and organizes images and other media similar to the danbooru engine.

I was looking for an organization app for photos at the time, and Google Picasa was not as flexible as I desired. Having first tried the recently opened danbooru engine, I found it difficult to even install the dependancy chain - Ruby, Rails, postgre, and some other things - I could get nothing working.

I'm not sure how I initially found Shimmie after that. Most likely it was some form of google search, and the dependancy chain was short and handled completely by the XAMPP apache package.

Anyway, Shimmie was as flexible as I wanted, but not exactly... complete. Being open source, I decided to dive into the code and change it around to my liking.

Been there ever since, contributing to the theme engine and trying to make useful extensions for the app.

Next few days, I'll start posting about some of the extensions and theme I've been working on.