-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doesn't seem to work #4
Comments
Hm. Me too... |
Same here. I also noticed a warning "Error loading plugin 'yard-sinatra'", so I did:
Not sure other info I can get than my env info:
Using yard 0.7.2 and yard-sinatra 1.0.0. |
yard 0.7.3 and yard-sinatra 1.0.0 also fails. tried with the debug and verbose output in the previous comment. There were no load errors or other indications of problems, it just doesnt appear to do anything. |
Sorry, github tells me, for some reason that "Notifications for new comments on this Issue are off.", so I didn't get email notifications about this. I won't have time to investigate until next week or so. It is definitely not related the the Sinatra version. It's probably some changes in Yard... |
Not working for me either: Using sinatra (1.3.1) Looks like a really useful tool however! |
With yard 0.7.4 I don't get an error but these warnings instead:
and the routes seem to get documented as if they are normal methods. |
Confirmed working with yard 0.7.4 (Well, working in the sense that the stuff is documented. I get the same warnings as tomdz) [EDIT] Starts messing up and duplicating methods if you add tags |
✨ I summon thee, @lsegal! ✨ |
I have same duplication problem too. Here is example: https://gist.github.com/1639920 |
Ah, this is interesting. The duplication comes from the fact that YARD now auto-detects DSL syntax and generates a method (via macros) if there is a docstring attached to them in the "explicit form", or if there are tags attached to the docstring. The "explicit form" is when you have a '##' on the first line of the comment, in the form: ##
# This is an explicit docstring
get '/foo' ... In this case, both YARD and yard-sinatra are each creating separate methods. One solution is to not use the '##' explicit form, but if you have First, perhaps YARD should not detect DSL methods that are not valid method names. statement like However, this would not solve scenarios like: I should point out that you can bascially get the behaviour of this plugin using the macros feature. The gist that @ql pasted can be rewritten as: # The API
class Api
# @macro [attach] sinatra.get
# @method $1
# @overload GET '$1'
# Says hello
#
get '/hello' do
body "hello"
end
# The bar method
get '/bar' do
body "bar"
end
end The above works with just The only problem with this code is that users have to define the macros manually (you can see this done in the first |
For reference, yard-sinatra could define macros programmatically using: include YARD::Parser
include YARD::CodeObjects
SourceParser.before_parse_list do |files, globals|
globals.__attached_macros ||= {}
['get', 'post', 'put'].each do |name|
doc = "@method $1\n@overload #{name.upcase} '$1'"
macro = MacroObject.create("sinatra.#{name}", doc, P("Object.#{name}"))
(globals.__attached_macros[name] ||= []) << macro
end
end And handlers would not be needed. |
This makes sense. Thanks a ton, I'll look into this as soon as I have time. |
I just tried the suggestion made by @lsegal while using
The macro works fine as suggested for |
@javanthropus, just add |
@lsegal, I tried adding Am I just doing something wrong? |
@javanthropus you shouldn't need to remove the macro, you can use both the |
Thanks for your help, @lsegal. After trying a few more things, I came to the same conclusion as you regarding my present options. I figured the plugin would need to contribute something here that the macro alone couldn't handle anymore. |
Doesn't work in yard 0.8.1 |
Any ideas on how either the macro approach or the yard-sinatra plugin could work for extensions, so that is DSL routes and settings defined as a class-scope function and called in self.registered(app) ? |
Would overwriting the |
On a related news: It seems to work on the first parse and if you force a reparse. |
This looks really helpful, but doesn't seem to work with current versions, 1.1.3 or 1.1.2, of Sinatra. I'm not getting the routes documented from
yardoc
and I get an empty array fromYARD::Sinatra.routes
The text was updated successfully, but these errors were encountered: