Article RSS Feed

Installing the part_attachments Extension

Tue, 06 Feb 2007 10:08:00 GMT

I really should have updated this earlier. I've renamed my attachments extension. Full installation instructions are:


   cd RAILS_ROOT/vendor/extensions
   svn co http://soxbox.no-ip.org/radiant/svn/extensions/admin_parts/
   svn co http://soxbox.no-ip.org/radiant/svn/extensions/part_attachments/

If you want to have all the image manipulation goodness, you'll also need fleximage and rmagick installed.


   cd RAILS_ROOT/vendor/plugins
   svn co http://beautifulpixel.com/svn/plugins/flex_image
   gem install rmagick

I'm pretty sure the rest of the information in the last two blog posts is accurate.

Page Asset Management II

Tue, 02 Jan 2007 17:09:00 GMT

I’ve now finished:

a way to upload asset for a page that hasn’t been created yet. If you upload an asset and subsequently don’t save the page, it’s still left orphaned though (probably just have a rake task to clean.

Caching. Currently using the exact same mechanism as the rest of radiant (ie. 5 minute expiry and stored in yaml files). Not the best approach for either large assets or manipulated images.

So that leaves:

a nice way to edit/delete images
validation
tests
confidence that you can use this without screwing up your data/life/mind.

But I’ll probably put those off for the moment.

Page Asset Management

Tue, 02 Jan 2007 16:59:00 GMT

I’ve been toiling away at another Asset Management extension – originally I started just playing round with Keith Bingham’s extension, but I’m pretty much dumped all that code now.

http://soxbox.no-ip.org/radiant/svn/extensions/part_assets

This extension requires that you’re running on the mental branch, and that you also have my admin_parts extension installed:

http://dev.radiantcms.org/svn/radiant/branches/mental/ http://soxbox.no-ip.org/radiant/svn/extensions/admin_parts

Features of this extension:

Images are linked to each page, rather than being global.

Local images can be displayed with:
<r:image name=”monkey.jpg”/>

Images from another page with:
<r:find url=”/some/page/name> <r:image name=”monkey.jpg”/> </r:find>

Images can be manipulated using FlexImage. Just dump a transform_name.flexi file into ‘app/views/assets’ and you can transform images:

app/views/assets/polariod.flexi

@image.resize! :size => '100x100'
@image.border! :size => 3
@image.shadow!

And in the page:

<r:image name=”monkey.jpg” transform=”polariod”/>

There’s also a default.flexi that all images are passed through – these files contain just ruby code and get passed both the @asset and the owning @page, so you could do default transformations depending on the type of page involved.

If FlexImage isn’t installed, the extension can continue to be used as a basic asset management system.

This isn’t complete. I don’t have:

a way to upload images for a page that hasn’t been created yet.
a nice way to delete images
much in the way of validation
anything in the way of tests (it’s probably going to crash early and often)
any caching whatsoever (your CPU will likely get choked if you try running this in production with transforms under even slight load)
any confidence that it wont destroy all your data or kill your first born child (use at own risk)

I’m pretty excited about how this extension is turning out – I’d love some feedback, and any offers of patches are always welcome.

AdminParts Extension

Fri, 08 Dec 2006 17:13:00 GMT

I think given my glacial pace of development that dumping my branch and going with extensions is the way to go. Herewith, my first radiant extension.

I’ve had a bit of a play with giving extensions access to the admin pages. I’ve gone with the concept of having ‘AdminPart’ classes. A page class has an admin_parts array, listing the admin part classes, ie.

Page.admin_parts = [TitleAdminPart, ExtendedMetadataAdminPart, PartTabAdminPart]

These are rendered through corresponding partials under an admin_parts directory (ie, TitleAdminPart becomes admin_parts/_title.rhtml). The page controller then passes off to each of the admin parts to save their data back to the model.

I’ve got an extension that implements this (in a very rough way), and an proof of concept example.

http://soxbox.no-ip.org/radiant/svn/extensions/

The only noticable change from having the extension installed is that at the moment when you save a page, the parts are saved off regardless of whether the save of the entire page is successful. Doesn’t bother me at the moment though.

I'm Back

Fri, 10 Nov 2006 16:19:47 GMT

Sorry for the long absence.... not that there was anybody listening. Because Radiant has shifted since I last set foot here, I've moved off most of my changes and pulled in a fresh copy of the 'mental' branch to play on. Hopefully I'll get something done this time.

Custom routing for plugins and tests

Thu, 06 Jul 2006 11:53:00 GMT

Haven’t had as much time to play lately as I’ve been put onto a new project at work which is taking up a fair bit of my thinking time, but I’m slowly pushing ahead.

Revisions 16 and 17 are in with a nice little feature:

I decided to have a go at updating the rails version to the latest trunk, just to see what would happen, and had most of the functional tests failing with wierd nil errors. The cause of this was the use of named routes combined with misuse of the with_routing function.

When you use ‘with_routing’ in a test, the new set of routes that are used will be used instead of those defined in routes.rb. The radiant test code was assuming that the previously defined named routes were still available. Rails also had a quirk where any named routing method would, instead of throwing a NameError, as it should, instead attempted to look up the old controller/action using the new naming rules. Since the with_routing in radiant was used to add a default route (’:controller/:action’) all the old named routes would map to their instead.

With the rewriting of rail’s routing code, the named routes will now fail with a cryptic error about calling a method on nil. When the routes are replaced, the named route helper methods still remain on controllers, but they will fail instead of looking up the route (they should really get removed, but i don’t see how that could be done safely).

To work around this, I’ve added a mechanism to allow the addition of extra routes through the Radiant::CustomRoutes object. Call Radiant::CustomRoutes.register with a block that accepts an normal rails route mapper, and the Radiant::CustomRoute.activate method will add those routes in during a route reload.

The tests also make use of this to add additional routes for testing purposes by using the “with_radiant_routing” helper.

This stuff should be great for adding radiant plugins that want to include extra controllers in the administration interface (or to anywhere on the site really). Bonus.

Rails Obverser Bug Update

Fri, 30 Jun 2006 17:19:56 GMT

My bug report to rails was picked up and fixed. Them boys is fast. Pity that named routes appears to be broken in the current trunk, so I’ll have to leave off updating the rails external. But after fiddling around trying to see why it’s broken, I realised that it didn’t matter. My problem was that I’d been playing with my behaviors in the ”/app/models” directory – but they’re behaviors and should be getting loaded from the ”/app/behaviors” directory anywhere – and those files are loaded before the observer is registered. Doofus.

Haven’t had a chance to progress much further today. Ate more than my fill of indian at lunch, and have spent most of the day struggling to stay awake. I have whipped up a little faux-page object that delegates rendering back to a controller, so I should be able to go about writing the comment handler with all the functionality of a full rails controller. Suprising how easy that was. I’ll probably have the comments working either Monday or, if I have time, sometime this weekend, and then everybody can start telling me what I’m doing wrong (and bombard me with offers for cheap pharmaceuticals – should put some filtering into it).

After that it’s a toss-up between expanding the plugin system for radius (specifically – adding migrations and adding extra admin controllers should be easy for plugins) or pushing ahead with the extra functionality that I need to migrate The Groggy Squirrel over to radiant. I should really do the later, but the former seems like more being more interesting and the fact that it might be really disruptive is a good justification.

A Mess of Changes

Thu, 29 Jun 2006 18:05:02 GMT

Have checked a lot of stuff in in an unfinished state at the moment. Can’t make up my mind about things, but hadn’t done a checkin since yesterday.

I’ve moved what was previously called Asset to be the new Page object, and what was previously Page is now LegacyBehaviorPage. This was originally done because I thought single-table inheritance wasn’t giving me what I wanted (searching on a subclass wouldn’t return subclasses of that) – I think my problem was just that the subclasses hadn’t been created yet, so it didn’t know to search for them.

I’ve added in a BehaviorPage object, which should be pretty much a straight replacement for behavior. It’s got all the same methods, so it should be possible to just change existing behaviors to extend BehaviorPage instead of Behaviour::Base. I might move Page back to Asset and make this class the new Page.

Added a rough CommentablePage behavior using the new BehaviorPage style of behavior. Test for displaying comments are done, but still umming and ah-ing over how to handle the submission of comments. Should I register a new controller or should I have a behavior that handles comment submission. As silly as it might sound, I’m leaning towards the latter – I might make a fake child of a CommentablePage that is only returned by find_page_by_url.

Oh, and I added some logging to PageContext so that I get the full backtrace of errors during a radius tag render. Debugging is so annoying when “Wrong number of arguments(0 for 1)” embedded in a page is all you have to go on.

Damn you Observer

Wed, 28 Jun 2006 22:12:47 GMT

Damn. Found a Rails Bug – if an observer is created before a subclass (in this case, when UserActionObserver gets instantiated before my new CommentablePage object), then observations don’t apply to the subclass.

Now I have to decide between patching that in (and potentially getting disrupted when rails catches up) or just making sure that things load in the right order. Annoying. I think I’ll go for the former.

Single Table Inheritance

Wed, 28 Jun 2006 10:56:43 GMT

Starting on the changes that are going to make this a real branch – starting to make changes to the database that will change that precious data and stop you from just switching back without some sql magic. Here be dragons.

Just checked in single table inheritance (Revision 8) – this will allow the adding of extra data to pages by linking them to other database models. Next is the migration of behaviours to become subclasses of page so that table associations can be simply described there. I’ve split out some of the functionality of Page into an Asset superclass, paving the way for pages that don’t have PageParts or Layouts (I’m thinking Images, Redirects).

My first step to this has been done in Revision 9 where I have made the behavior method of Page private and expanded the list of delegated methods. This way everything is talking to a page object, and behavior is just a hidden implementation detail – this way you can extend the system by subclassing page instead of adding behaviors.

I’ll be updating this site to run the latest version of R.O.C. at every opportunity, so if things break, it’s probably because I was stupid.