On Mon, 2010-09-20 at 13:41 -0700, Mike Orr wrote: > On Sun, Sep 19, 2010 at 6:36 PM, Ben Bangert <b...@groovie.org> wrote: > > On Sep 13, 11:49 am, Mike Orr <sluggos...@gmail.com> wrote: > > > >> Can it be made into a request method so you don't have to pass the > >> request object? That would be more OO. > > > > Yea, maybe request.link? request.url would conflict with the webob url > > property. > > It's a good enough name for now. It does connote an entire <a> rather > than just the URL (cf. webhelpers.html.tags.link_to()). But I can't > think of a better name. > > > > >> Or do you have to paste the markup text from the subprojects and > >> convert all "autoclass" to "class" by hand? The problem with this is > >> it would gradually drift out of date unless you went through every few > >> months looking for differences between your docs and the originals, > >> which would take a lot of time. > > > > Yea, we're going to have to compose copy/paste to an extent, from the > > other docs. > > Well, hopefully '.. autoclass' will work if the package is installed. > WebHelpers and other packages uses '.. autoclass' extensively. It's > one thing to copy ReST documentation from another package. It's > another thing to reconstruct the ReST from the HTML or paste it > directly from the docstrings. which is what you'd have to do if > autoclass doesn't work.
The problem isn't the tool's ability to find the implementation and use its existing documentation. That we have down pretty much cold, and it will work just fine. The problems are instead: - :ref: links buried inside docstrings of the existing BFG implementation docstrings which point at BFG narrative documentation. These will point off to nowhere when the same documentation is rendered as part of the Pylons doctree. - Ben wants to create a facade Pylons API for all (most?) BFG APIs. Existing BFG implementation docstrings have :class:, :function:, :method:, etc references buried inside then, which, for Pylons will point to the wrong places (each will point at the BFG dotted name instead of the Pylons dotted name). I am willing to remove "unnecessary" references from BFG docstrings to help slightly here, but I don't think it will help much. I can't remove them all: their existence is deliberate, to help people navigate the BFG docs. I think the best bet would be some sort of "facade generator" which not only creates the Pylons facade module(s) for BFG functions, but which also scrubs or modifies the docstrings of BFG APIs. - C -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
