Some Changes

已查看 0 次
跳至第一个未读帖子

Daniel Yoder

未读,
2009年7月9日 03:49:352009/7/9
收件人 ruby...@googlegroups.com
Hello Team,

Well, at long last, I've made a commit! I am not going say I'm back (just yet) because it would be premature, but it felt good to really dig in.

The commits are on edge and I'd like it if you guys reviewed them, especially Eero since I changed some of the stuff he'd done, including some semantics of the matchers and (yet again) the actual accept header matching. Hopefully, everyone will be on board and see the utility of the changes, but, if not, please yell about it here and let's hash it out.

A quick summary of the main changes:

- The matchers don't raise exceptions any more with bad arguments. Instead, you are expected to make sure you pass them good arguments. I made this change because we were ignoring the exceptions anyway, with rescue nils and the like. I replaced this with code that simply double-checks the arguments before trying to create matchers. You have to be careful here, because sometimes false or nil are valid option values, so you have to use #key?

- I got rid of Matchers::Base. Most of the matchers weren't actually using anything from Base (at least nothing of interest) so it was a bit misleading to have them all inherit from there.

- The extension matcher was simplified a bit. You can now use false or true to match no extension or any extension. You can also use '.*'. The use of the empty string to match no extension is gone. Also, I believe you can now match regexps, but I haven't written any tests for that.

- The Requested matcher changed a bit, mostly just because the requested attribute has changed. Basically it just takes the MIME types associated with a given extension and parses them using the Accept parsing. It then simply appends the accept array. Bam! This works because our Unspecified MIME type has gone away (see below).

- I pulled Accept out of Request (it is complicated enough to warrant its own file) and broke the parsing up a bit. The value stored now includes all params, including the q values. This is generally useless, but hews closer to the spec. In particular, it turns out params are actually part of the sorting criteria. So now you'll get something like this:

    [[[ 'text', 'html' ], { 'q' => 1.0 }]]

for 'text/html'. I will add a #to_media_types to get back the old style array.

- I rewrote the #include? method, which I know will grate on automatthew, but I think this time I might actually have done something useful. My hand was forced because I am now just comparing arrays. We convert the match pattern to a media type and then use a case statement to do the matching, which is handy because I can collapse all the various cases into a one liner (well, 3 lines). I'd still like to add regexp matching here in some elegant way (which was how I started out using case in the first place) but for now this is okay.

- I got rid of the Unspecified MIME type, but replaced it with something very exciting: the ability to just pass a lambda as a matcher. So instead of trying to implicitly handle the use case where you want to match on something or the equivalent of the nil value, you can just create a lambda with whatever boolean chaos your heart desires:

  default_to_html = lambda { |r|
    r.extension.nil? or r.requested.include?( :html ) 
  }
  on( :get, %w( foo ), :where => default_to_html ) { 
    'we default to html, but you can also ask for it' 
  }

(With extensions of course, you can still just include false in the list of extensions, but trying to do that with #requested struck me as opaque compared to simply defining a lambda that spells out the trouble you're stirring up.)

- The content-type now gets defaulted to text/html unless there is an extension. Put another way, we no longer use the accept header to default the content-type. This makes sense to me, after thinking about, since it is quite possible to have a rule fire that isn't actually based on the preferred content-type. One possibility here is to actually set the content-type based on a requested, accept, or extension match. Even this is problematic since they can be used in combination, which could lead to some very hard to debug problems. So for now, we keep it simple.

That's all! The tests all pass, albeit partly because I got rid of or modified some of them. But only when the spec seemed to have changed, I swear! I have to say, I think we have done much better on the specs (a lot of credit here I think goes to Eero) which made it possible for me to even attempt these changes. Without that, I would have been forced to be much more tentative.

Dan

Krishna Krishnamaneni

未读,
2009年7月10日 15:11:362009/7/10
收件人 ruby...@googlegroups.com
awesome. I will spend some time checking it out this weekend.
--
Regards,
krishna krishnamaneni.

John Haltiwanger

未读,
2009年7月17日 03:36:222009/7/17
收件人 rubywaves
Just to butt my head in and say hello. Though I too hesitate to
announce a return prematurely, I couldn't help but mention that it is
great to see such significant Waves activity on my first trip back to
the internet after a bit of wilderness.

Well actually I'd like to say also 'Damn Dan! That lambda matcher is
fresh!' and 'Ten beers and twenty cheers to rue for the spec work.'

More than that to come, to be sure.
回复全部
回复作者
转发
0 个新帖子