Controller class considered harmful?

[Dan North]

Hi Ramazers.

I have a couple of questions/thoughts/ramblings that are kind of related, and I'd appreciate your views.

Firstly, does the Ramaze::Controller class have to be, well, a class? By doing that it owns my controller class hierarchy. If instead it were a module, I could have:

class MyEndPoint < WhateverIWant
  include Ramaze::Controlled
  map '/end'

  # ...

end

It was actually one of my colleagues - Ola Bini, the jruby guy - who pointed out that he didn't like web frameworks owning the controller class hierarchy so I thought I'd pitch it to you guys. You could be fully backwards compatible simply by having:

class Ramaze::Controller; include Ramaze::Controlled; end

Secondly the word "controller". It's really an endpoint. And when I start using the REST helper it becomes more like a reified operation on a resource and even less like a controller, so I can do this:

class ReifiedOperation < Ramaze::Controller  # this "feels" wrong
  helper :rest
end

module Books # books as a resource

  class Search < ReifiedOperation  # Books::Search represents a book search operation
    on_post
    def create_search_query
      # ...
    end

    on_get
    def execute_query
      #
    end
  end

  class AnotherBookOperation < ReifiedOperation
    # ...
  end
end

Of course resource- and operation-oriented REST is only one of many architectural web styles. So I guess what I'm asking for is for the guts of Ramaze::Controller to be pulled out into a module called Ramaze::EndPoint (or something) and then included back into a deprecated Ramaze::Controller class for compatibility.

Is there any appetite for this? If so I can have a go at doing it myself.

Thanks,
Dan

[Michael Fellinger]

That sounds quite fun, how about making a fork so we can work on that?

^ manveru

[ara.t.howard]

On Jun 25, 2008, at 9:20 AM, Dan North wrote:

module Books # books as a resource

  class Search < ReifiedOperation  # Books::Search represents a book search operation
    on_post
    def create_search_query
      # ...
    end

    on_get
    def execute_query
      #
    end
  end

  class AnotherBookOperation < ReifiedOperation
    # ...
  end

end

while you're at it how about

  post 'path' do |params|

  end

  get 'path' do |params|

  end

  action 'path' do |params|

  end

which would completely eliminate the private vs public method issue on controllers - only things declared to have an http interface would.  which suggests possibly

  http :action_name do |params|

   end

  http :action_name, :get do |params|

  end

  http :action_name, :posrt do |params|

  end

or something similar.

cheers.

a @ http://codeforpeople.com/

--

we can deny everything, except that we have the possibility of being better. simply reflect on that.

h.h. the 14th dalai lama

[James Tucker]

On 25 Jun 2008, at 16:20, Dan North wrote:

>
> I have a couple of questions/thoughts/ramblings that are kind of
> related, and I'd appreciate your views.
>

Seems like a good idea. Such an architecture certainly would have
helped quite a bit in a couple of our apps.

[Dan North]

2008/6/25 ara.t.howard <ara.t....@gmail.com>: 

On Jun 25, 2008, at 9:20 AM, Dan North wrote:

[...]

while you're at it how about

  post 'path' do |params|

  end

  get 'path' do |params|

  end

  action 'path' do |params|

  end

which would completely eliminate the private vs public method issue on controllers - only things declared to have an http interface would.  which suggests possibly

  http :action_name do |params|

   end

  http :action_name, :get do |params|

  end

  http :action_name, :posrt do |params|

  end

or something similar.

Sure, why not - that's really nice! I was just using the syntax that the built-in rest helper provides as an example. On one project where they are using this model they have similar sugar to provide the default behaviour. Unfortunately they are using merb rather than ramaze but I've got them at least evaluating it.

The more the merrier, I say!

cheers.

a @ http://codeforpeople.com/

--

we can deny everything, except that we have the possibility of being better. simply reflect on that.

h.h. the 14th dalai lama

Cheers,
Dan

[Brian Marick]

On Jun 25, 2008, at 2:39 PM, ara.t.howard wrote:
>
>
> while you're at it how about
>
> post 'path' do |params|
>
> end
>
> get 'path' do |params|
>
> end
>
> action 'path' do |params|
>
> end

Which raises a question I've been wondering about. Do the things
defined by "post" etc. have to be methods? Can they be Command objects?

Why, you ask?

Well, I've noticed that "business-facing" or "acceptance" tests are
too hard to write, whether you use a TDD/BDD framework like test:unit,
Fit, Selenium, tests drawn in OmniGraffle <http://www.exampler.com/blog/2007/07/13/graphical-workflow-tests-for-rails/
>, or whatever.

I've come to think they won't get easy enough to write unless
frameworks are changed to make it so. I've also come to think much of
that change would also help manual exploratory testers (who are
becoming respectable again even in the automated testing world). (Just
the ability to undo --- the canonical justification for a Command
object --- would be immensely handy.)

One of my goals is to change a web framework in those directions, and
I've tentatively settled on Ramaze, but I haven't done anything more,
though it's possible Laurent Bossavit and I will take a hack at it the
Monday of the Agile2008 conference in Toronto.

For more on what I'm aiming at, my summary of my keynote at the last
Google testing conference:
<http://www.exampler.com/blog/2008/03/23/an-alternative-to-business-facing-tdd/
>
(Note shameless name-dropping.)

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick