Tom, Hmmmm. Interesting. So if I can get by with:
return HoboFields::MarkdownString.new(foo) then maybe I can just whip up a simple attr_accessor implementation that wraps the instance variable in the correct type whenever accessed? I'm totally on board with this project of using the native ruby type system (rather than metadata) to make HoboFields independent from ActiveRecord. I think that's a great idea. There seem to also be bits of Rapid that would have to change. For example, I think there is a standard_fields method that calls the intersection of attr_order and content_columns, the latter a very ActiveRecord-ish field. Alternatively, a person could give up on standard_fields and tags that worked like <field-list fields="*"/> for the time being. There really is an AR-ish "interface" out there that people have tried to mock. There's a Validateable plugin that exposes a #errors object on plain old ruby objects. Obviously to work with Rapid forms, any object would have to have that as well. It really makes no sense that everything in your app should be tied to a db row. The Java world went hog wild with separation of concerns, but I really feel the bloated model classes that usually tend to mix persistence, business logic, and presentation concerns are the single biggest weakness of the Railsy way of doing things. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Hobo Users" 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/hobousers?hl=en -~----------~----~----~----~------~----~------~--~---
