Jon, That example I posted was made up on the spot. Several of the idioms in there are various libraries I've written for internal use, particularly for web services. I don't need to re-render the html form, or redirect anywhere, like in a browser, which greatly simplifies the controller actions.
On Dec 4, 5:54 am, Jon Hancock <[EMAIL PROTECTED]> wrote: > Paul, > Your sample code look interesting. I've been wrestling with various > forms of my own. Is there a larger set of code you can share? > I'm hoping to publish a full working subset of my app soon. Some > examples from you may help me get to the finish line quicker. > thanks, Jon > > On Nov 29, 2:10 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: > > > I like using exceptions in my code, it keeps things simple and easier > > to read. I'm less concerned about speed, and "Flow Control" > > correctness. In Merb, I have to investigate my model in several > > different ways, then raise an exception for each (permissions, > > validation failures, database connection lost, etc...). For example, > > here's one of my controller actions: > > > def create > > @article = Article.new(params[:article]) > > raise Unauthorized unless requester.may_create?(@article) > > > if @article.save > > head(Created, :location => uri(:article, :id => @article.id)) > > else > > raise RecordInvalid.new(@article.errors) > > end > > end > > > And this even fails in cases where there's something wrong saving the > > record that has nothing to do with validations (a 500 server error, > > rather than a 4xx client error). If datamapper were to do the > > exceptions handling thing, that action could be reduced to two lines: > > > def create > > @article = Article.create(params[:article]) > > head(Created, :location => uri(:article, :id => @article.id) > > end > > > That would be my favorite solution. But Sam says exceptions are slow, > > and I'll agree that there are applications for DM other than web apps. > > I choose to raise exceptions, and let Merb's exception handler render > > the right error page. > > > On Nov 28, 2:45 am, Alex Neth <[EMAIL PROTECTED]> wrote: > > > > ... > > > The basic problem is that there is no guarantee of what "false" means > > > when returned from save. If you change the contract to be that false > > > means there was a validation error, and state exceptions are thrown in > > > any other instance of save failure, then I could write correct code. > > > I think this would be an acceptable middle ground, for speed concerns. > > The most common error, a validation failure, takes the fast path of > > save returning false. The other cases are rarer, and could be safely > > handled by exceptions. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
