I had a go at this. However, your change is in the area of to_param. My problem actually comes from the sort of code one finds in content_tag_for:
rails / actionpack / lib / action_view / helpers / record_tag_helper.rb: def content_tag_for(tag_name, record, *args, &block) prefix = args.first.is_a?(Hash) ? nil : args.shift options = args.extract_options! options.merge!({ :class => "#{dom_class(record, prefix)} #{options[:class]}".strip, :id => dom_id(record, prefix) }) content_tag(tag_name, options, &block) end rails / actionpack / lib / action_controller / record_identifier.rb: def dom_id(record, prefix = nil) if record_id = record.id "#{dom_class(record, prefix)}#{JOIN}#{record_id}" else dom_class(record, prefix || NEW) end end As you can see there's an explicit call to record.id in there and I think this sort of assumption is used in several places in the view layer. So I'm looking for a way around this and wonder if there are other ideas than adding a non-key id property to all classes involved in views. Patrik On Feb 17, 5:52 pm, Patrik Sundberg <patrik.sundb...@gmail.com> wrote: > Cool. I'm using the 3.0.0beta so will try the latest commit. > > Thanks. > > On Feb 17, 3:00 pm, Martin Gamsjaeger <gamsnj...@gmail.com> wrote: > > > > > Patrik, > > > You were hitting a current limitiation in rails3_datamapper! Check out > > the latest code, I just committed an intermediate fix to your problem > > (natural keys should work now, composite keys still not). This was > > buried in my code for some time already (thx to Andy Ferra), but I had > > forgotten to push it. > > > checkout http://github.com/dkubb/rails3_datamapperforlatest codes. > > > Note though that the latest code at dkubb/rails3_datamapper isn't yet > > compatible with rails master. If you need rails master, use my fork > > athttp://github.com/snusnu/rails3_datamapperIshould warn you though, > > there are quite some internal changes in my fork, so if you have some > > time still, I'd recommend keep on using official > > dkubb/rails3_datamapper for some more time. Eventually, the stuff from > > my fork will be merged. > > > cheers > > snusnu > > > On Wed, Feb 17, 2010 at 13:32, Patrik Sundberg > > > <patrik.sundb...@gmail.com> wrote: > > > Hi, > > > > I have a few models not using a Serial id as primary key, instead > > > using a unique string related to the domain of the objects. > > > > When using them with rails3 (using rails3_datamapper) I run into > > > problems with things like content_tag_for who seem to assume that all > > > objects have an id property. > > > > I wanted to ask if anyone else has come across this before and if they > > > have any tips on good ways to deal with it? > > > > I am thinking that I could add something like this to keep rails > > > happy: > > > property :id, Serial, :key => false > > > > Haven't tried it yet, thought I'd check if there were any good > > > techniques I could reuse before getting into it. > > > > Thanks. > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "DataMapper" group. > > > To post to this group, send email to datamap...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > datamapper+unsubscr...@googlegroups.com. > > > For more options, visit this group > > > athttp://groups.google.com/group/datamapper?hl=en.-Hide quoted text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to datamap...@googlegroups.com. To unsubscribe from this group, send email to datamapper+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.