Hey Jason, That is a bit much (feature not complexity-wise). Normally feed lists would push entries for create/update and on some rare occasions destroy (no longer friends.) I will be including the last example for a delete scenario, but will not be including delete hooks for all models. The delete methods will still be accessible, but you will have to add your own hooks for the other models you would like a history for. You will be able to look at the friend entries for examples.
On a side note, I have decided that i will (and have) add view caching to the FeedEntry class. I currently have it working and it works beautifully. I just have to design the partial it will render and cache. I am no css guru so I promise very little as far as it's appearance. Perhaps, there is a css guru interested in taking a look at the views before its final? -- Matthew Peychich (8mile) On Sep 26, 2008, at 5:15 AM, Jason Keenan wrote: > > Sounds interesting. Asking a bit much but it would be great to be > able to have an event history and a feed, if that makes sense. While > 'creation' events are of interest to others in feed form, it would be > good to be able to look at the 'history' of my events as a user or > administrator too, including deletion events. Just a thought. > > Looking forward to looking at the update. > > Jason :) > On 26/09/2008, at 6:21 AM, Steven A Bristol wrote: > >> >> On Thu, Sep 25, 2008 at 4:10 PM, <[EMAIL PROTECTED]> wrote: >>> >>> hey steve (and all), >>> >>> The primary problem with the current feed system lies in it's >>> inability to preserve state due to it's dependency on the associated >>> object. In order to remedy this, a status column was proposed. >>> This >>> is a good short term fix, but I don't think it is best for the long >>> run. What I am currently working on is not a modification of the >>> current system but a new system altogether. Back when i initially >>> wrote the feed system I didn't plan it out to well (sorry about >>> that) >>> and as a result, it has a pile of issues including >>> feed_item.partial. >>> The new system does not deal with the associated object directly. >>> It >>> uses a version of that object that gets cached at time of creation >>> which preserves state. With this type of a system, no status column >>> is needed and each friending will exist as a separate event. Also, >>> the system provides textual title and description methods . Also, >>> Steve and I talked about the possibility of view caching or allowing >>> simple view helpers such as link_to which is still open to debate. >>> All in all, it would remote the issue of status as well as trying to >>> pull a partial on NilClass. The models are done (with the exception >>> of view stuff since I'm still debating that) and I am hoping to >>> have a >>> branch with it available within the next week for people to look at >>> and talk about. >>> >>> >>> questions, comments, concerns, or anything else? >>> >>> -- Matthew Peychich >>> (8mile) >>> >>> >>> >> >> >> Sounds good! I'm looking forward to seeing it. I am loving the model >> generating views and storing them in the db. Awesome. >> >> >> steve >> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lovd by Less" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/lovdbyless?hl=en Who loves ya baby? -~----------~----~----~----~------~----~------~--~---
