[Radiant] Help with Radiant/Rails Implementation

2008-11-19 Thread Chris Parrish
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
___
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant


Re: [Radiant] Help with Radiant/Rails Implementation

2008-11-19 Thread Mohit Sindhwani

Chris Parrish 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.

___
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant