Hi Steven > yep that works - cheers!
I updated the example a tiny bit to allow mass-assignment to work. I'm sure it could be taken further and made to behave like a DM::Resource object, but using it's parent object for all the storage of the data. > btw, can we expect a "rich mans" EV in the future? I'm not sure. It really depends on whether people like you, Piotr, and others who are interested in the community take it on. I prefer to have it so features are driven by real need, rather than just adding it because I may need it at some point ... and I'm fine with waiting until someone gets to the point of being motivated enough to write the code to solve a specific problem. I firmly believe the first step for something like this is to get it working first, then to refactor and abstract the code. What I actually would expect is that someone start with an approach like what I outlined in the gist, and take it to the extremes and make the proxy object duck-type a DM::Resource object. Once you have that, you can work backwards and start refactoring it until you can configure it via a DM::Model-like DSL. It might even be possible to extract some of the DM::Model DSL methods into a shared modules/ classes that DM::Model and DM::EmbeddedValue can share. The first step is probably the hardest, and I think like DataMapper itself it will require a bit of experimentation until the correct approach is revealed to you. -- Dan (dkubb) -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to datamapper@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.
