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.

Reply via email to