portable perspectives

a blog about programming, life, universe and everything

cleaning up bin/gen

I started writing gen/administration, leaving the xhtml cleanup/helper creation for later, since I want a little more testing in place before.

But why I want all this testing? If you try to follow my reasoning I’ll try to give an explanation.

What is needed for gen admin

It is quite simple to think of a generated part/admin as something that loads different scaffolded parts for each one of the Og.managed_classes and adds some more stuff like setup, a proper <SystemPage> and so on.

This cleanly translates to something like

    def run
     create_admin_files
     create_parts_for_classes
    end
    
    

where the latter can be done either via creating multiple ScaffoldGen objects and calling their run method or making AdminGen inherit from it and using super multiple times.

The Problem

But how does bin/gen handles this? Well it basically doesn’t, it just loads a specific file for every generator and let it handle the setup directly, thus each generator
  • accesses parameters directly via ARGV
  • creates a generator and binds it to $generator

This makes the above idea messier to implement cause there would be a time dependency on who sets the global, and on the access to the shared ARGV. Also even if now it is possible to add generator-specific usage messages, the excutable script would not tell you anything about them, cause it relies on a method-local text.

So what?

Well, I need some small simplistic tests for the other generators, so that I can then refactor everything and be sure I have not messed up anything.

And in the process I think I can make the whole thing easier to test for people hoping to add other generators, thus making it easier to contribute. IMO letting third party stuff merge nicely into the framework is the best service we can offer to developers.

AddThis Social Bookmark Button

Leave a Reply (use Markdown Syntax)