Forum: Radiant CMS Help with Radiant/Rails Implementation

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Chris P. (Guest)
on 2008-11-19 21:00
(Received via mailing list)
I'm stumped and could use some help/advice -- time to show your mad
hackr skillz...

Please forgive the length, there's some needed background involved.


Background
----------
SnS TextAsset models track their dependencies (each model parses its
content and identifies <r:javascript> or <r:stylesheet> tags within).
Easy.

Then, when any model is updated, it announces this to all the other
instances who check their dependencies and, if they depended on the
updated model, adjust their own effectively_updated_at date.  So far,
still easy.


The Problem
-----------
Saving the effectively_updated_at date -- not so easy.  TextAsset models
have callbacks -- none of which should fire when only saving
effectively_updated_at.

Specifically, these are:

    * Rails automatic timestamps (created_at, updated_at)
    * before_update and before_create callbacks (via Radiant's
      UserActionObserver to set created_by and updated_by)
    * My own before_save callback which parses the content to update its
      own dependencies (mentioned above)
    * My own after_save callback to announce to the other models that
      this one's been changed (mentioned above)



Current Solution
----------------
The current solution is to store effectively_updated_at in a separate
model with a has_one relationship to its TextAsset.  That way changes to
the date are done directly through that sub-model and so doesn't trigger
the callbacks on the related TextAsset.

This works but it *really* bugs me having a separate table just for one
field (a field that really belongs to another model).


Help?
-----
Can anyone think of some clever solution that will let me move this
attribute into TextAsset?

How could I update and save a TextAsset's effectively_updated_at
attribute without waking up those callbacks?

Or am I just being too picky?


Ideas
-----
I'm open to anything here, really.  My current ideas include:

    * Make the TextAsset model explicitly handle all the above callbacks
      (no more auto timestamps, no more using Radiant's built-in
      observers).  And then, in those callbacks, inspect an instance
      variable flag (say, @exit_callbacks) to end each routine.  It's a
      bit messy but it also replaces some mess in dealing with the extra
      table.  Mostly I don't like that it ignores Radiant's and Rails
      built-in tools.  I'm also not sure how to make current_user
      available to a TextAsset (but that's probably not hard).

    * Add some way to disable callbacks on a particular instance (like
      maybe:
      http://github.com/cjbottaro/without_callbacks/tree/master).  Seems
      neat but also sounds like a lot of code for one attribute.  I've
      never used it either so I'm not sure how reliable it is or if it's
      solid across different Radiant/Rails versions.

    * Save to the effectively_updated_at column directly using the
      ActiveRecord's #connection method and SQL commands.  Never done
      this before and it sounds like, well, yuck (but maybe I don't
      understand it well enough either). And could this even be done in
      a db-agnostic way?

    * Your idea here...


Thanks,
Chris
Mohit S. (Guest)
on 2008-11-19 21:16
(Received via mailing list)
Chris P. wrote:
>    * Your idea here...
>

Probably way out on a limb here (blame it on the time), but how about
keeping that 1 table for that 1 column!  OK, before you relegate it to
Junk Mail :) here's an explanation:

If I remember correctly (and I may be completely wrong), SnS supports
certain types of extensions?  If that's the case, then it could be that
all extensions using/ relying on SnS can assume the existence of this 1
table for storing information that is updated via callbacks and is
intended to bypass all the other callbacks that you mentioned?

(Even if you're not supporting extensions, this could be a model/ table
that general extensions can use for storing exactly this kind of thing).

Cheers
Mohit.
This topic is locked and can not be replied to.