$ ./script/generate comatose_migration --upgrade --from=0.5

15 comments

07.23.06 @ 13:49 Jon Gretar said...

Damn… This is getting cooler and cooler. I am 100% behind the thought of these things being done in plugins. Allowing people do build websites in a modular fashion. I myself is working on a tumblelog plugin(use your plugin as an inspiration on how to do things right) and hopefully soon others will have similar plugins for blogging, links or guestbooks etc. That way you would build your personal website for example by installing the Comates+Tumblelog+link plugins.

The only problem I’m facing is that then administration would be split into multiple areas. Thus making you manually travel between site.com/tumbler and site.com/comatose etc.

I’m wondering if we should make some way to allow plugins of these kind to sense each other. By adding themselves to some array so various plugins could at least provide links to each other.

Other way would be to make an plugin-admin plugin that’s universal. And plugins of these kinds add administration tasks into that plugin. much like plugins can have rake.task files. Of course that would mean that our plugins would be dependant on another plugin so I don’t know if that’s the best idea.

But I’m just floating this idea forward. I think the first idea to allow plugins to sense each other and provide links would be something easy and simple but something that would really simplify things for users of multiple content plugins.

Write a reply...

07.24.06 @ 01:59 RelyAS @ Work » Matt McCray is my RoR Hero of July said...

[...] Matt McCray announced Comatose v0.6 yesterday, and gave mere mortals like myself a great lesson in developing Rails plugin. [...]

Write a reply...

07.24.06 @ 03:54 GJW said...

That sounds super useful, and I, also, greatly appreciate this, and things like this, being implemented as plugins.

But using a meta-admin plugin wouldn’t necessarily make other plugins dependent on it. Just make it a plugin that detects & supports certain other admin plugins, or a generic admin plugin interface. call it at site.com/MetAdmin, site.com/metadmin/tumbler, etc. You could make it so that you can still call site.com/tumbler/admin as well, or build the other (“client”) plugins with a flag to disable their built in admin interface, or a before_filter in the ApplicationController that caches the result of metadmin detection and turns it on or off based on such, or doesn’t turn it off but does a redirect to the metadmin version, etc, etc.

Write a reply...

07.24.06 @ 08:58 San said...

There’s a minor bug when you generate the admin controller. In the comatose_admin.rhtml layout the javascript include for ‘comatose_amdin’ is misspelled (it should be ‘comatose_admin’).

Keep up the great work! (can I buy you a beer to add rollback support?)

Write a reply...

07.24.06 @ 09:46 San said...

Can we get an option to make the slugs with underscores instead of dashes, or is there a reason behind the dashes?

Write a reply...

07.24.06 @ 12:31 Dan Kubb said...

IMHO slugs with hyphens are better than underscores. (and URLs in general)

Google has stated that when they see a URL with underscores, they index the words as a single phrase, not the individual words. So “ruby_rails” would only show up for searches on “rubyrails”, and not “ruby” or “rails”. Google has advised people to use hypens if you want URLs to be indexed by the individual words. Google does not consider underscores to be word separators.

(Search for GoogleGuy and underscore to find out more about this)

There’s also the issue of how a URL looks when hyperlinked and it contains an underscore. An underscore could easily be mistaken for a space by a non-technical person, or someone with vision impairment. Not a big deal when people are bookmarking or cut & pasting the URL, but could cause problems with people writing down URLs.

Both of these reasons aren’t major, but if you have no strong preference either way, I believe hyphens are usually a better choice.

Write a reply...

07.25.06 @ 11:04 manuel said...

Both controllers extend your ApplicationController

So it is now possible to use Rails’ helpers?

Thanks again for this fantastic piece of code, Matt!

Write a reply...

07.27.06 @ 19:41 hello said...

FYI, this isn’t working with ozimodo. I haven’t tried to figure out what the problem is, but her e are the errors.

on install, at the very end:

/Users/hello/p/ozimodo/vendor/plugins/comatose/install.rb:2: warning: already initialized constant RAILS_ROOT

trying to run ./script/generate comatose_migration:

/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:123:in `const_missing’: uninitialized constant THEME_DIR (NameError)

Write a reply...

07.28.06 @ 12:46 mikkel said...

Running 0.5…(yeah yeah)...

All of a sudden I get error 500 on some comatose pages:
Errno::ENOENT (No such file or directory – getcwd):
/vendor/rails/actionpack/lib/action_controller/routing.rb:269:in `expand_path’
http://www.hill107.com/about-hill-107 works but http://www.hill107.com/faq doesnt…

Any suggestions??

Write a reply...

07.28.06 @ 13:17 mikkel said...

“solved” it by restarting lighty and not just fcgi listeners…weird…

Write a reply...

07.28.06 @ 13:57 M@ said...

Jon & GJW: A Macro-Admin plugin is an interesting thought. It’s skirting rather closely the Plugin/Engine line. But I could see if there were other embedded plugins installed having some sort of admin umbrella would be useful…

But I’m not sure that wouldn’t be something you’d want to define in your application instead of another plugin. I think if such a plugin were made, it would need to allow plugins to register themselves (perhaps as tabs, or something), but also allow the application’s controllers to register themselves. I guess what I’m saying is that you’d want the same admin for the entire application, not just the plugin’s admins.

To me, it’s not even the plugins that make the idea of a Macro Admin, or whatever you’d call it, interesting. It’s the CRUD craze that’s catching on. With CRUD, you generally support the full Create, Read, Update, and Delete in your controller and limit access to the sensitive actions using a before_filter.

You don’t really want to re-create the controllers for an adminstration site. I guess you could extend the CRUD controllers and just have different views/layout. Or you could just have different layouts for the restricted parts. But either way seems a little un-DRY.

I haven’t really thought through the requirements, but if you could register controllers with an generic admin, that could definitely be handy.

Of course, you get into the whole “Trying to design the one-admin-to-rule-them-all” problem.

A simpler solution would be for embedded plugin’s to register with the admin, if it exists, and the admin would provide some HTML to put at the top of the plugin’s admin layout. It could be an ‘Administration bar’, similiar in concept to Blogger’s bar at the top of their blogs

San: Thanks, that bug is fixed in newer versions.

San & Dan: About underscores versus dashed, I land with Dan on this one. I like dashes for the reasons he stated and because, well, I think they look better in the URI.

That said, you can edit the slugs. They are pre-filled with JavaScript, but you are free to change them if you’d like. In fact, if you customize Comatose, you can tweak the comatose_admin.js to pre-fill the slugs with _’s instead of -’s.

(At the bottom of the file it extends the String object, adding a toSlug method)

manuel: You can use Rails helpers and partials in the layouts now, yes.

hello: Ozimodo? Hmmm… Well, I’m not familiar with it, but I can tell you that first error is a warning, so you can safely ignore it.

The second one isn’t from Comatose, at least, not directly. I take it Ozimodo is theme-able—Do you know if it’s using the Theme Support plugin? It’s looking for a THEME_DIR for something, and it’s not defined.

Perhaps it’s a plugin load order issue. If it’s doing any theme stuff in the application.rb, it might be an issue—Comatose does require ‘application’. But like I said, I’m not really familiar with Ozimodo.

mikkel: Ah the joys of Rails deployment. Still, that is bizarre.

Write a reply...

07.28.06 @ 22:42 mikkel said...

m@ it was actually running for a couple of days…I think a rake remote:cleanup somehow messed it up…

Write a reply...

08.26.06 @ 01:59 San said...

Hey Matt, is comatose still working with edge? The admin interface isnt mapping.

Write a reply...

08.26.06 @ 20:32 M@ said...

San: Well, Comatose has never “officially” supported edge rails. And probably won’t until it’s more stable. nnThat said, I do have some experimental support for edge rails in there. However, it doesn’t “just work” like it does in the official releases. To get the administration working, I had to add an empty comatose_admin_controller.rb file in the app/controllers folder… Weird, but seems to work.nnAs edge rails gets closer to being released, I’ll spend some extra cycles on making sure it works nicely.n

Write a reply...

08.27.06 @ 09:45 San said...

Ah, terrific, that fixed it. Thanks! I agree, Weird! Might be a good bug to file now before they release 1.2.

Write a reply...

No trackbacks

Trackback link: