Mike Hix avatar Mike Hix committed 2be9f81 Draft

Plugins.rdoc corrections.

Comments (0)

Files changed (1)

 processes managing different URI routes, you'll quickly find benefit from
 refactoring common code into reusable components.
 
-As mentioned in the {Strelka Tutorial}[link://oTutorial_rdoc.html] section,
-Strelka breaks out functionality into a set of core plugins that allow you to
-cherry pick the capabilities you need. It's easy to create your own plugins for
+As mentioned in the {Strelka Tutorial}[rdoc-ref:Tutorial] section, Strelka
+breaks out functionality into a set of core plugins that allow you to cherry
+pick the capabilities you need. It's easy to create your own plugins for
 optional loading of shared behavior into any number of handlers.
 
-This page is a walkthrough for creating an example Strelka plugin that
-logs all HTTP accesses to a SQLite[http://www.sqlite.org/] database.
+This page is a walkthrough for creating an example Strelka plugin that logs all
+HTTP accesses to a SQLite[http://www.sqlite.org/] database.
 
 == The Basics
 
 A Strelka plugin is just a module under the Strelka::App namespace that is
 extended by the Strelka::Plugin class. Once extended, the plugin participates in
-the Strelka::HTTPRequest to Strelka::HTTPResponse lifecycle, and is able to
-alter it via hooks.  The plugin only participates for handlers that load it via
-the <tt>plugin</tt> declarative.
+the <tt>request</tt> -> <tt>response</tt> lifecycle, and is able to alter it via
+hooks.  The plugin only participates for handlers that load it via the
+<tt>plugin</tt> declarative.
 
 Lets start by creating and naming an empty plugin.  We'll call it
-<tt>DBLogger</tt>.
+<tt>dblogger</tt>.
 
 	require 'strelka'
 	require 'strelka/app'
 hooks absolutely require you to <tt>super</tt> at some point, so the
 request/response chain passes through your plugin.
 
-=== fixup_request
+[\fixup_request]
 
-Make any changes to the Strelka::HTTPRequest that are necessary before
-handling it and return it. This is an alternate extension-point for
-plugins that wish to modify or replace the request before the request
-cycle is started.
+	Make any changes to the <tt>request</tt> that are necessary before handling
+	it and return it. This is an alternate extension-point for plugins that wish
+	to modify or replace the request before the request cycle is started.
 
-=== handle_request
+[\handle_request]
 
-Handle the Strelka::HTTPRequest and return a Strelka::HTTPResponse. This is the
-main extension-point for the plugin system. Without being overridden or extended
-by plugins, this method just returns the default <tt>Mongrel2::HTTPResponse</tt>.
+	Handle the <tt>request</tt> and return a <tt>response</tt>. This is the main
+	extension-point for the plugin system. Without being overridden or extended
+	by plugins, this method just returns the default Mongrel2 response.
 
-=== fixup_response
+[\fixup_response]
 
-Make any changes to the Strelka::HTTPResponse that are necessary before
-handing it to Mongrel and return it. This is an alternate extension-
-point for plugins that wish to modify or replace the response after the
-whole request cycle is completed.
+	Make any changes to the <tt>response</tt> that are necessary before handing
+	it to Mongrel and return it. This is an alternate extension- point for
+	plugins that wish to modify or replace the response after the whole request
+	cycle is completed.
 
 == Completing the Example
 
 For our logging purposes, we want to hook the <tt>fixup_response</tt> method. We
 won't be altering the response itself, but just reading attributes from it and
-squirreling them away. Most notably, the Strelka::HTTPResponse has access to the
-Strelka::HTTPResponse object, and visa versa. You can find more detail for these
+squirreling them away. Most notably, the <tt>response</tt> has access to the
+<tt>response</tt> object, and visa versa. You can find more detail for these
 hooks in the API documentation for Strelka::App.
 
 Here's the complete plugin.
 		end
 	end
 
-== Final Notes
-
-When handler starts and the plugin is initialized, the database and the logging
-schema are created, and every request performs an <tt>insert</tt> with the data
-we're after. There's plenty of room for improvement here (configurable db
-location, prepared statements), but hopefully that gives you a first-round idea
-of how easy it is to add pluggable functionality to Strelka.
+Handler startup creates the database and the logging schema, and every request
+performs an <tt>insert</tt> with the data we're after. There's plenty of room
+for improvement here (configurable db location, prepared statements), but
+hopefully that gives you a first-round idea of how easy it is to add pluggable
+functionality to Strelka.
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.