Top Level Namespace

Defined Under Namespace

Modules: Enumerable Classes: Maveric, Module, StandardError, Symbol

Instance Method Summary collapse

Instance Method Details

#log4r ⇒ Object

Maveric: A simple, non-magical, framework

Resources

Maveric can normally be found on rubyforge with it’s project page here.

Maveric is also listed at the RAA as maveric. This page lags a bit behind rubyforge.

Maveric’s home away from home is code.stadik.net which contains many other things.

Version

This is 0.1.0, the first real release of Maveric. It’s rough around the edges and several squishy bits in the middle. At the moment it’s still operation conceptualization over algorithm implementation. It’s usable, but kinda.

Ahh, 0.2.0, wherein we reevaluate ourselves and our ways and eliminate the cruft and improve our efficiency. We have a new implementation of Route going on, they’re now regexps. The ServerError class has been removed, now any subclass of Exception can be raised. One of the larger differences is greater customization of Maveric and Controller instances through extending methods. These are touched upon in their respective docs. Have fun!

I was hoping for a 0.2.1 with refined documentation, updated plugins, and a better execution path. Instead I got all of that as well as altering basic implementation details and adding pre and post processors for Controller and refinment of Maveric’s. With the degree of changes we get 0.3.0! Nothing but good stuff yo.

Authors

Maveric is designed and coded by blink of #ruby-lang on irc.freenode.net

Licence

This software is licensed under the CC-GNU LGPL

Disclaimer

This software is provided “as is” and without any express or implied warranties, including, without limitation, the implied warranties of merchantability and fitness for a particular purpose. Authors are not responsible for any damages, direct or indirect.

Maveric: History

Maveric was initially designed as a replacement for Camping in the style of a Model-View-Controller framework. Early implementations aimed to reduce the amount of “magic” to 0. Outstanding magic of Camping is that nothing is related due to the reading, gsub-ing, and eval-ing of the Camping source file Also, even the unobfuscated/unabridged version of Camping is a bit hard to follow at times.

However, the result of this initial attempt was a spaghetti of winding code, empty template modules, and rediculous inheritance paths between the template modules and a plethora of dynamically generated classes and modules. I got more complaints with that particular jumble of code than any other, evar.

The next iteration of Maveric was a seeking of simplification and departure from the concept of cloning Camping and its functionality and settling for Camping-esqe. At this point, I started talking to ezmobius on #ruby-lang and their Merb project. We talked a bit about merging and brainstorming but my lone wolf tendencies stirred me away from such an endeavour, but I came away a compatriot and inspiration for a new routing methodology inspired by Merb’s. The result is the Route that’s been stable since, only varying in method placement and data management.

After building to a version that stood on it’s owned and was able to run a variance of my website as functional as the Camping version. I noticed a few tendncies of my coding and refactored. I also redesigned the concept from a modules that included the Maveric module to that of subclassing Maveric, which is a Mongrel::HttpHandlerPlugin. This allowed the running of Maveric apps without using Mongrel::CampingHandler as well as not worrying about namespace clobbering.

Because ehird from #ruby-lang was whining about it so much I removed its dependancy on Mongrel sooner than later. Maveric should now be very maveric.

Because Maveric 0.1.0 worked, but still didn’t do things the way I wanted I revised and refactored codes and algorithms into 0.2.0 which will hopefully be all that I want. Everything beyond 1.0.0 will be improvements and extensions.

Features

  • Optional sessions

  • Flexible and strong route setup

  • Sharing of a Controller between Maveric instances is facilitated

  • Inheritance is highly respected

Not so Maveric

Maveric has additional classes to allow you to run Maveric behind different http server implementations. CGI, FastCGI, and Mongrel are supported. If another service exists that you’d like to have supported please submit a patch of a good reason why.

NOTE: Beyond Maveric 0.1.0 extensions have not been touched, future releases should include updates. AFAIK they should work.

For these examples we will utilize the simplest functional Maveric possible

require 'maveric'
class Maveric::Index < Maveric::Controller
  def get
    'Hello, world!'
  end
end

To use CGI:

Maveric.new.dispatch.to_s

To use FastCGI:

require 'maveric/fastcgi'
::Maveric::FCGI.new(MyMaveric)

To use Mongrel:

require 'maveric/mongrel'
h = ::Mongrel::HttpHandler ip, port
h.register mountpoint, ::Maveric::MongrelHandler.new(MyMaveric)
h.join.run

However, if your script is mounted at a point other than /, use the :path_prefix option to adjust your routes. This affects all routes generated from MyMaveric.

::Maveric::FCGI.new(MyMaveric, :path_prefix => mountpoint
h.register mountpoint, ::Maveric::MongrelHandler.
  new(MyMaveric, :path_prefix => mountpoint)

NOTE: Due to rampant debugging and benchmarking there is a plethora of pointless time checks in place. Anything greater than the WARN level on the logging output tends to output a good deal of information. DEBUG is not for the meek.



141
 
# File 'lib/maveric.rb', line 141

require 'log4r'