Hi Dan, Great feedback. I agree that my use of :failure to contol the return value is a bit smelly, but I was grasping at straws. Let's forget about that one.
I will play around with some ideas locally before I make another recommendation and/or release a plugin or patch. Here are the ideas I want to play with: * A DM configuration setting that chooses what happens on validation failure. * A hook that gets called on validation failure. An exception can be thrown from here or a nil return could be forced. * Using save/create methods with different names (e.g. create_ex) for the different validation failure behaviors. I would like this if I could think of good names :-) (The bang names are already used for the non-validating versions.) ..tony.. On Mon, Dec 15, 2008 at 2:03 PM, Dan Kubb (dkubb) <[email protected]>wrote: > > Hi Tony, > > > Based on all the feedback, it is clear that there is not much consensus > > around my idea. Before I give up, I have another suggestion: we could add > an > > option to create() and save() to specify how validation failures should > be > > handled. Specifically: > > > > :failure => :throw # throw exception on validation > error > > (save and create) > > :failure => :return_nil # return nil on validation error > (only > > for create) > > :failure => :return_resource # return resource instance on validation > > error (only for create) > > :failure => :nil # default behavior (save and > create) > > > > In addition, there could be a way to change the default behavior for save > > and create through DM config options. > > > > This could be through a plug-in or folded into the trunk. > > > > Thoughts? > > I would certainly welcome and encourage anyone who wants to make > changes to the public API to make it into a plugin first. I think > real code has alot more value than theoretical changes, which has very > little, if any. I say if you have *any* idea, write the code as a > plugin and try it out for a while to see how you like it. I've been > surprised many times by how a seemingly good idea didn't work at all > in practice, and what I thought was a bad idea turned out to be > awesome. > > One of the things we try to do with DM's API is make the code very > "ruby-ish", sticking with common idioms and conventions that (appear > to be) more widely used in the Ruby community. We try to make it so > that someone who is used to using PORO (plain old ruby objects) can > pick up and understand DM. For example, note how we store attributes > as ivars, so if you have an :email property it will store the value in > @email by default. Also take how we do Collections, where we've gone > to great lengths to make Collection behavior identical to Array, even > thought underneath the entries are not loaded until a "kicker" method > is called, like #to_a or #each. Keeping the DM API clean and easy to > use is my #1 priority. > > We still have a few conventions borrowed from other ORMs that we > review regularly and try to find better alternatives. As you > mentioned earlier in the thread, the Resouce#new_record? is a bit > ugly, and will probably be deprecated in favor of Resource#new? and > Resource#saved?, with the latter mostly to help clean up the presence > of somewhat ugly conditional syntax: I'd much rather write "if > user.saved?" and "if user.new?" than "if !user.new_record?" and "if > user.new_record?". > > With that said, I've never seen an API in a popular ruby library where > throwing exceptions vs. return values was configured based on the > arguments provided. I'm not entirely convinced that as a solution it > will be any cleaner than what we have now. Please though, try to > prove me wrong with actual code :) > > Dan > (dkubb) > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" 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/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
