Make it easier to extend Camping

[camping]

Make it easier to extend Camping

[busbey]

extend in what manner? < works pretty good.

[kylekyle]

The camping-is-really-just-your-module-evaled-from-a-string hackery prevents people from extending Camping in a straightforward way using mixins and whatnot. This, for example, will not work:

module Camping::Controllers
  class Index 
    def get
      "hey, you forgot to give camping an index page!"
    end
  end
end

If your replace the "Camping::Controllers" with "YourModuleName::Controllers" it will work. But that means you need to know the name of the app beforehand. You can extend a particular app, but not camping itself.

I think you could use autoload and append to the Camping::S string to fake it in the current version, but it would be nice to make camping a little less meta in that area.

[busbey]

i see. like changing the model handling stuff involves writing in a string so you can module_eval in camping, module_eval in each of the extant camping apps, and do a sub on Camping::S.

yeah, that's rough.

I'm not sure autoload will work, because it only runs the first time a symbol is referenced, so I suspect by the time you'd write your change the useful hook points would be gone.

[judofyr]

Equipment tried to solve this. Maybe we can take something from there?

[busbey]

way to give me shiny to go chasing after.

[judofyr]

I might try to revive Equipment…

[judofyr]

The only reason Mab and ActiveRecord uses the funky "extend by evaling + putting themselves into Camping::S" is because they want to appear as built into Camping. It's a part of Camping. It's what you get.

Other extensions want to be explicit. You don't want a require to magically introduce new behavior in your app. I think these can safely be implemented using included-hooks.

[activestylus]

@judofyr The best example I've seen of easy extension is Cuba https://github.com/soveran/cuba#plugins

Overall its a really great framework. I enjoy it a lot more than Sinatra or Rails for example. I do wish they had not gone the block route for their controller actions. If they had taken a page from Camping and gone with actual methods (which Camping leverages with R) it would be the perfect ruby framework. As it stands you are forced to call your routes as strings. Which totally sucks, but you cant have everything I suppose

[karloscarweber]

Hi Friends,

I've been messing around with this for a few days. A robust plugin system is already built in to Ruby. include and extend do almost all of the work required. To making Camping easier to extend we probably need to introduce lifecycle hooks into certain actions that take place, and provide clear documentation on how to write a plugin for Camping, how to encapsulate state, and how to interact with Camping's state.

If we take Cuba, for example, their plugin code looks like this:

  def self.plugin(mixin)
    include mixin
    extend  mixin::ClassMethods if defined?(mixin::ClassMethods)

    mixin.setup(self) if mixin.respond_to?(:setup)
  end

This is pretty close to just include, with the added benefit of mixing in Class Methods and running a setup script. A useful addition would be before and after filters. We have a plugin for that: CampingFilters. You can use it like this:

require 'camping'

Camping.goes :Nuts
module Nuts
  include CampingFilters
end

The downside is that the CampingFilter's plugin overwrites the service method. If we had more than one plugin that relies on service then we'd be out of luck.

I propose we build something like CampingFilter into Camping itself and give our plugins hooks for common actions:

• before and after, routes are called
• before a view lookup is performed, with an option to skip the view
• before a render is performed
• before method_missing is called in a controller (used as a Controller's dispatcher)
• etc...

I also propose we map out and document the formal Camping request sequence and available instance variables and values and how to use them. For example:

• When @env, @request, @root, @input, @cookies, @state, @status, @headers, and @body are set and what they contain.
• When Routes are built and fed into controllers.
• Examples for common use cases, changing headers, status, etc.. Saving @state in a session.
• Every method that will return the request, where to access them, and how to use them.

I suspect that mapping out how Camping flows will give us a clear understanding of which event hooks are missing, that would be useful to add.