mattmccray

 
« Comatose Screenshots | Home | Comatose v0.5 »

Comatose v0.4

» Published July 06, 2006 under Comatose, Rails, Software

I’ve just checked in a big update for Comatose.

Here’s a list of the major changes from the CHANGELOG:

[version 0.4]
  * Added keywords field
  * Abstracted text filters into a micro plugin structure, default 
    support for
     - Textile
     - Markdown
     - RDoc
  * It will only show the filters as a choice in the admin if you have 
    the necessary libraries for the filters to function.
  * Added ComatoseController.hidden_meta_info = [] as a way of showing/hiding 
    the meta fields
  * The comatose_migration generator now accepts an --upgrade flag which
    will create a micro migration that only has the new fields in it
  * get_root_page will now support returning an array of root pages to show
    in the admin page list
  * Created some initial tests... (Can you tell I'm not a test _first_ guy?)
  * Inline rendering now handles :silent flag -- it will just return and 
    empty string if :silent=>true
  * Modified all the internal references to ComatoseController to self.class.
    The views reference controller.class. Redirects redirect to :controller=>
    self.controller_name or controller.controller_name (action and view 
    respectively). This show allow you to sub-class the ComatoseController.

As always, I’ve tried to keep the README up to date with the changes.

Upgrading from the previous version...

I’ve added a couple of fields to the comatose page model… If you have already installed the comatose plugin, and have the add_comatose_support migration applied, you can get a migration of just the new fields by running:

$ ./script/generate comatose_migration --upgrade

There’s only one other feature that I know I’m going to add in the near future—The ability to re-order the pages. It won’t be a big deal when I release that one though, I already have the field I need in there.

Feedback

As always, check it out, kick the tires, etc. Let me know if you have any issues/questions/suggestions…. darthapo at gmail dot com


14 comments

07.10.06 @ 00:33 scott said...
Hi Matt,

In ComatoseController#show, you store the page title and keywords as session values. The best I can tell, they’re only accessed from comatose_content.html. When I comment out the session assignments and replace the references to the session hash in comatose_content.html with attribute lookups on page (page.title and @page.keywords), everything seems to work fine.

Is it safe to remove those session assignments so that Comatose isn’t storing per-user session values?

Thanks, Scott
07.06.06 @ 18:29 Chris Corriveau said...
Matt,

This is a great idea and script/plugin. I really liked the first version and this version is even better. Thanks for the new filters.

One suggestion is to add a TinyMCE filter. I think this would make it a great plugin option for most.

Chris-
07.06.06 @ 19:18 scott said...
The migration upgrade worked great. Thanks.
07.06.06 @ 21:14 Jesse Andrews said...
slow down … I keep having to install a new version of the plugin every day!
07.07.06 @ 05:48 mikkel said...
Ok…i fiannly got it working. It was my rails setup that was broken for some reason….

A few notes:

When choosing at custom layout comatose is unable to locate templates called with render :partial

comatose doesnt have access to ApplicationHelper methods…

Solving these two issues would be really kewl…

Ill try to look into it, but dont count on me solving anything ;-)
07.07.06 @ 09:24 John Long said...
Dude. If you keep this up I’ll have to discontinue the development of Radiant. :-)
07.07.06 @ 10:18 M@ said...
Chris: Thanks. Interesting thought about using Tiny MCE. I’ll consider it…

Jesse: Heheh, sorry — I’ve already got another version on the way, too. It supports sending parameters to pages when using inline rendering (render :comatose), and fragment caching. But I’ll hold off releasing it until the page reordering is done as well… Which is say, probably this weekend.

mikkel: Glad to hear you got it working!

1) Hmm… locating templates when called from a partial? Or when using inline rendering? It’s designed NOT to use a layout when called inline.

2) Yeah, no access to the ApplicationHelper methods… I’ve thought a little about this one… At this point, I’m not sure what I’m going to do about it. For now, you could probably create a lib/comatose_binding_ex.rb that includes the application helpers methods:

require_dependency ‘application_helper’
class ComatoseBinding
include ApplicationHelper
end

Or something to that effect.

John: Ha, I wouldn’t worry about that! I’m not done with Radiant — I still have tests to do, I know! ;-)
07.07.06 @ 11:34 mikkel said...
the render partial problem occurs when using “normal” render, not inline…

routes.rb
comatose_root “”,:layout=>“application”

in application.rhtml

“shared/navigation”%>

unable to locate shared/_navigation!!!

Would be nice with a fix for this…
I try to look into it….
07.07.06 @ 17:08 Coda Hale said...
In addition to the ApplicationHelper, some of my helpers depend on methods of ApplicationController. Any suggestions on how to accomplish this?
07.10.06 @ 09:55 M@ said...
mikkel: Oh, I see. Initially Comatose runs completely from within the plugin. When it’s doing that, it sets the template_root on the ComatoseController to the plugin’s view directory. I’m pretty sure that’s what throwing off the partial rendering.

I don’t have any ideas, at the moment, of how to fix that other than running rake comatose:customize. That will copy the views into your application folder and let the template_root return to normal.

Coda: Well, that kind of depends on where you need the helpers—in the layout or the page content itself.

If it’s the layout where you need the helpers, you can modify the ComatoseController to sub-class ApplicationController instead of ActionController::Base. I’m thinking about doing this in the next version, but I haven’t made up my mind yet. I guess it wouldn’t hurt anything…

Its’ a bit trickier, however, if you want access to the helpers in the page content… It would involve monkey patching the ComatoseBinding and maybe a few other things.

scott: You bet—in fact the session variables are going away in the next release, so you’ll be ahead of the curve!
07.10.06 @ 17:01 Vrensk said...
I’ve noticed that the html templates use UTF8, which is A Good Thing, but that the preview does not do so. Adding

response.headers[“Content-Type”] = “text/html; charset=utf-8”

before the render call in preview solves the problem for me. I don’t know if it should be there by default, but I know that character encoding is a can of worms, and my fix could break someone else’s working setup (and mine too, in another project). Any thoughts?
07.10.06 @ 17:41 scott said...
A request(ion): How do you feel about adding a page cache hook in the cache_cms_page method so the app can make more fine-grained page caching decisions (in part to support finer-grained page-oriented authorization)? Obviously this can also be done via routes in many cases, so it is a “nice to have,” but it is definitely nice to have. :-)
07.10.06 @ 20:48 M@ said...
Vrensk: Well, personally, I think all text should probably be sent as UTF-8. Which is why the templates use it. But, as you noted, I didn’t do anything in the controller to force it’s output…

Perhaps I’ll add a flag for toggling the utf8 headers. By default, I think it’ll be turned off — but if anyone wants/needs it, it’ll be there.

scott: Hmmm… An interesting thought. Yeah, on my projects I’m using the routing to specify which parts of the page tree allows caching.

But I’m sure finer grained control wouldn’t go amiss. Especially since I’m about to add fragment caching for inline-rendering — and support for parameterized inline page rendering. (It’ll look like a call to a partial: render :comatose=>‘a-dynamic-page’, :locals=>{}. It’ll send the locals hash to the ERB context.)

I’m thinking maybe something like:

def allow_page_cache?(page)
# page is a ComatosePage
true # True caches, False doesn’t
end

There’d probably be an allow_fragment_cache? method too.
07.11.06 @ 12:40 scott said...
Works for me. Thanks in advance if you decide to incorporate it. I like the parameterized inline page rendering, too.

Now, if you just mokney-patch Rails to optionally render a Comatose page that matches the controller/action name after executing an action instead of rendering a filesystem-based erb view after actions as Rails does now, then the assimilation will be complete! :-)

– Scott

No trackbacks

Trackback link:

Please enable javascript to generate a trackback url


You may use Textile, or simple html tags (B,I). Feel free to use Emoticons too. Oh, and please limit yourself to only five links per comment. Anything more and you'll probably get detained by the spam police.