Enjoy!Cheap Trazodone Purchase Prednisone Buy Acomplia Buy Deltasone Purchase Butalbital Virility Gum Buy Oxytrol Order Oxycontin Cheap Zyvox Cheap Nimotop Cordarone Cheap Mexitil Order Lisinopril Buy Sumycin Aciphex Myambutol Cheap Kytril Buy Dostinex Professional Plasma Buy Zocor Cheap Ultram Buy Nexium Ultram Cheap Singulair Buy Septilin Cheapest Valium Bontril Buy Diabecon Buy Avapro Cheap Ventolin Lexapro Cheap Ambien Cheap Diovan Accupril Buy Lorazepam Buy Brite Paxil Avandamet Order Butalbital Purchase CLA Herbolax Cheap Didronel Monoket Famvir Order Lukol Ephedrine Purchase Flovent Buy Pamelor Buy Butalbital Order Diabecon Reosto Purchase Isoptin Buy Ativan Lotrisone Cheap Evecare Purchase Clomid Buy Hydrocodone Purchase Antabuse Order Prevacid Order Casodex Avodart Cheap Levitra Purchase Propecia Purchase Synthroid Cheap Eurax Norco Cheap Tramadol Ordering Didrex Buy Lexapro Cheap Shallaki Cheap Flovent Purchase Seroquel Relafen Buy Atarax Order Avandamet Dilantin Buy Urispas Protonix Lioresal Purchase Liv.52 Lotensin Buy Mexitil Buy Noroxin Purchase Septilin Biaxin Order Mentat AyurSlim Purchase Stromectol Order Aceon Order Depakote Order Zebeta Buy Ultram Mycelex-G Cheap CLA Cheap Danazol Purchase Coumadin Elimite Buy Retin-A Noroxin Touch-Up Kit Cheap Lukol Order Styplon Buy Superman Cheap Protonix Order Fioricet Evista Purchase Ophthacare Cymbalta Cheap Augmentin Order Avapro Order Pamelor Herbal Maxx Purchase Flomax Order Revia Order Atarax Cheap Cipro Purchase Aldactone Buy Norco Topamax Cheap Nirdosh Buy Capoten Buy Prednisone Cheap Ashwagandha Purchase Norco Order Flomax Order Zyloprim Order Norco Order Bontril Revia Purchase Miacalcin Buy Lioresal Order Zocor Order Ophthacare Purchase Deltasone Buy Exelon Order Himcospaz Cheap Loxitane Cheap Darvocet Cheap Norvasc Cheap Geodon Order Sinequan Buy Acticin Order Crestor Purchase Mentax Order Arimidex Purchase Abana High Love Cheap Accutane Cheap Xeloda Buy StretchNil Purchase Lasix Cheap Desyrel Purchase Bactroban Rhinocort Order Proscar Cheap Cystone Motrin Purchase Cozaar Buy Ambien Rocaltrol Order Diazepam Cheap Cardura Purchase Mycelex-G Order Acomplia Purchase Aleve Purchase Calan Order Altace Cheap Adipex Buy Coumadin Purchase Flexeril Purchase Acticin Buy Mentat Cheap Mentax Purchase Speman Cheap Claritin Purchase Tenuate Cheap Zovirax Purchase Pletal Cheap Reosto Buy Geriforte Buy Allegra Order Vantin Buy Loprox Femcare Liv.52 Order Geodon Cheap Purim Cheap Herbolax Order Nolvadex Order Himcocid Order Shoot Order Cardizem Cheap Copegus Sarafem Order Rogaine Purchase Styplon Buy Detrol Order Miacalcin Buy Monoket Purchase Celexa Purchase Urispas Order Eurax Purchase Rhinocort Buy Clomid Buy Shallaki Purchase Alprazolam Cheap Actos Aldactone Calan Order Darvocet Buying Viagra Cheap Celebrex Order Propecia Buy Tricor Purchase Xeloda Ambien Buy Lopressor Cheap Azulfidine Purchase Zimulti Buy Flonase Karela Purchase Purim Cheap Proscar Buy Rogaine Synthroid Propecia Buy Himplasia Cheap Starlix Buying Tenuate Order Nexium Purchase Karela Cardura Buy Adalat Buy Emsam Oxytrol Purchase Zestril Purchase Diarex Maxaquin Levlen Altace Cheap Femara Cheap Atrovent Purchase Cephalexin Buy Amoxil Penis Growth Buy Mevacor Cheap Rumalaya Cheap Plendil Cheap Pravachol Buy Sustiva Purchase Lotrisone Order Imitrex Purchase Aristocort Zovirax Retin-A Zerit Purchase Endep Purchase Nolvadex Purchase Mexitil Prinivil Buy Copegus Cheap Cytotec Human Growth Cheap Topamax Buy Plendil Order Lamictal Order Viramune Didronel Purchase Codeine Buy Cystone Buy Dospan Order Clonazepam Purchase Reosto Order Noroxin Cheap Phentermine Buy Karela Cheap Mentat Order Zanaflex Order Lortab Order V-Gel Imdur Order Hytrin Methocarbam Purchase Proscar Cheap Levlen Purchase Feldene Rumalaya Forte Order Prandin Prandin Purchase Allegra Buy Loxitane Himcocid Buy Diovan Purchase Lamisil Buy Pletal Cheap Lariam Buy Aceon Purchase Cytotec Order Evecare Cheap Lamictal

Which is a roundabout way of saying that, if there are developers out there would would like commercial work on Hobo projects, I could probably send some their way. I don’t want to be a middle man, and I definitely don’t want to end up getting embroiled into projects that don’t go smoothly, so… You’d need to be able to convince me that you know what you’re doing, know how to handle clients professionally, and are pretty handy with Ruby and Rails, even if you don’t (yet!) consider yourself a Hobo expert.

I even have a little project ready to go - something that James and I started but we’re both too swamped to move it forward.

If you’re interested, drop me a line at tom@tomlocke.com, subject “Hobo Project Work”. Thanks!

Once we get to Hobo 1.0, we’re thinking we might do something more structured along these via the hobocentral website. A job board for example, or perhaps even a Hobo consulting group, but for now we’ll keep it simple.

It just struck me that writing long blog posts instead of getting on with actually documenting this stuff properly is a bit silly. So instead, I’ve launched into The DRYML Guide, mark 2. This is going to be the definitive guide to DRYML and it will cover the whole language.

I’ve also started the work of moving to test/unit and shoulda. The plan is to move either the tests or the docs forward every day.

To whet you’re appetites, here’s the outline for the new DRYML Guide:

• What is DRYML?
• Simple page templates
• Defining tags - part 1
• The implicit context
• Repeated and optional content
• Defining tags - part 2
• Attributes
• Parameters
• before/after/append/prepend and without
• nested parameters
• extending tags and merging params/attributes
• aliasing tags
• polymorphic tags
• wrapping - restore and param-content
• Variables - set and set-scoped
• Taglibs
• Current limitations and other gotchas

Enjoy!

DRYML Generators

This is the big change in 0.8 — we’ve started using generators (gasp!) to create the automatic pages. If you’ve not been following along, you might wonder why the gasp. Well, we’ve always been quite opposed to using generators to automatically create a user-interface for your app. The reason being is that generators are really nothing more than copy-paste code re-use. Which as I’m sure you know is a terribly evil sin : ). The point being that if you’ve got five copies of something, and you want to change it, you’ve got to change it in five places, which is both tedious and error-prone.

Having said that, there’s one thing that generators are really great at, and that’s helping you learn. When you’re new to Rails itself, for example, it’s really useful to be able to look at the restful controller created by the scaffold generator. You learn at a glance how you’re supposed to use the provided API.

When it comes to DRYML, a natural first step when wanting to customise something in the UI, is to look at the source for that tag definition. The problem is that lots of the tags within the Rapid library are very unusual. Unusual in the sense that they’re not like the kind of tags that you would typically define in your own application. That’s because these tags have been written with no knowledge whatsoever of your application, they’re entirely generic. A good example is <show-page>, which does a remarkable job of presenting a reasonable looking page for any model that you throw at it. OK so you want to customise your <show-page>, so you go look at the source. Uh oh. All the logic for handling that generic magic is right there in the tag definition. As a result, we’ve noticed people copy some of these generic tricks into their own apps. This is really not a good idea — your app does not need to be generic, it’s specific to what you are doing.

So we don’t want DRYML generators because we don’t want DRYML to become WETML, but we would really like a generator-like approach to making DRYML, and Rapid, easier to learn. Here’s what we came up with…

The parts of Rapid that were very generic: the pages, cards and forms, are now generated. You can go look at the source code. You’ll find very simple code that’s been tailored to your application and is a good guideline for how you should write your own tags. But there’s a twist. The problem with generators is — what happens when things change. Easy! We just generate again and overwrite the old tags. Huh? What about my edits? That’s the twist - you don’t make any.

The generated taglibs are all written out under the directory app/views/taglibs/auto, and the rule is — you don’t edit anything within that directory. Instead, you use the powerful features that DRYML gives you to customise those tags. You can either extend them, which you’d probably do in application.dryml (using the new <extend> tag), or, you just call them and use DRYML’s parameter mechanism to tweak things to your needs.

This post is just to give you a heads-up of the thinking behind this feature, not to document how it all works, but here’s a quick example. Suppose you have a Story model, which has a title, and Rapid has automatically given you a show-page that uses that title as the main heading. But that’s not exactly what you want — you want the heading to always start with “Story:”.

So you mosey over to app/views/taglibs/auto/rapid/pages.dryml and find the tag definition for this page. It might look like this:

<def tag="show-page" for="Story">
  <page merge title="Story">

    <body: class="show-page story" param/>

    <content: param>
      <header param="content-header">
        <a:project param="parent-link">&laquo; <name/></a>
        <h2 param="heading"><name/></h2>

        <a action="edit" if="&can_edit?" param="edit-link">Edit Story</a>
      </header>

      <section param="content-body">
        <view:body/>        
        <field-list fields="status" param/>
      </section>
    </content:>

  </page>
</def>

That is much easier to understand than the old fully-generic definition of <show-page>. If you never saw it, take my word for it - it was scary : ). We can clearly see that <show-page> is calling <page>, adding a title, a couple of css classes to the <body> and some main content using the <content:> parameter. The content section itself is also very straightforward — we can see a header and a body, a link back to the owning project, the heading in an <h2> tag, the edit link, and so on.

OK so we want to add that “Story:” prefix to the heading. Well we can clearly see that the <h2> in question is parameterised — the parameter is heading. So, thanks to the magic of DRYML, we can simply create our app/views/stories/show.dryml as follows:

<show-page>
  <prepend-heading:>Story: </prepend-heading:>
</show-page>

Now that’s not quite as obvious as simply hacking on the generated file, but once you get used to DRYML’s parameter mechanism, it’s really very easy. The beauty is what happens when you change your app. Say, for example, you decide you don’t want an edit page for stories, so you remove that action in the controller. The page generators are re-run automatically, and the edit link will disappear from your show-page. You’ve got the best of both worlds: the ease of learning that you get from generators, and the flexibility to change that Hobo has always had.

I’m pretty excited about this change. I think it will take the ease of working with Hobo to a whole new level, and we really haven’t compromised any flexibility. How’s that for change we can believe in ;o).

• Change Log

Enjoy!

Expect breaking changes as always (until we get to 1.0 of course), and expect more than normal, because this is a fairly big release.

I’ve created a page on the github wiki to collect advice for upgrading your existing apps. That page will grow over the next few days, but to get you started, here are the main things you definitely need to do.

First, Hobo in general:

Upgrade gem to 1.2 (you don’t have to do this but it’s so much faster)

$ gem update --system

Add the github gem server as a source (so you get will_paginate)

$ gem sources -a http://gems.github.com

Now you can upgrade Hobo

$ gem update hobo

Then, for your app:

You need to run some generators again. Be careful not to overwrite your code! The ‘d’ option to see the differences is useful. You might want (with the user model in particular) to just create a new blank Hobo app with the hobo command and compare the files manually. Run these generators:

• hobo
• hobo_rapid
• hobo_user_model
• hobo_front_controller

From there, go check out the page on the wiki

I’ll follow-up shortly (heh) with a post about what’s new in 0.8.

• http://twitter.com/tablatom

I’ll pretty much only be using this to let anyone that’s interested know what I’m up to with Hobo at a given time. Don’t expect to see “brushing my teeth” or anything like that : )

This is going to be pretty much write-only, too. I’m not good with distractions. So apologies in advance if I don’t respond to your responses.

So we need a bit more visibility, we need it to be clear where we’re going and what we need to do to get there. Of course we need this anyway, to make it easier for folk to contribute to the project. We need to blow the cobwebs off our trusty Hobo Lighthouse.

Tis done! head over there and see how neat and tidy it all is : ) And if you think you’ll be keeping an eye on the tickets, and maybe even filing your own now and then, be sure to read the home page which explains how we’re organising the tickets.

The idea is that we’ll track pretty much everything as tickets, not just bugs and feature-requests, but bigger to-do items such as testing tasks and documentation that needs to be written. I’m not sure everything like that is in there right now, but most of it is.

In other news, we’re long overdue a release. This one is going to be 0.8 because it’s got some cool new features. I was hoping to get it released this week but that looks a bit doubtful now. I see that I’ve got 28 open tickets so I better get cracking!

Of course those who wanted to know if the Hobo project itself was still active, if they knew where to look, would have headed over here and would have found things to be very much alive. That’s all very well but I really must start blogging more!

OK where were we? About the time of the last post I was just about to head off to Railsconf with some very interesting news. As often happens in life, and even more often with anything related to software development, things didn’t quite pan out the way we expected. I do have news though, oh yes, even better news than I had before in fact.

At Railsconf we announced our plan to form the Hobo Foundation, a non-profit organisation to act as a conduit for companies that want to help Hobo succeed, and a way for developers to put some serious time into the project while still paying the rent. The driving force behind the idea was a company over in Washington D.C., Barquin International, who were to be the initial sponsor. The more we talked to Barquin, the more apparent it became that these guys really wanted to take Hobo seriously. They’re using Hobo in some very critical projects, the first of which rolls-out next month. To cut a long story short, we’ve arrived at a perfect solution which gets Hobo very much on track, and gives Barquin a close link with the on-going development: they’ve contracted me to work on Hobo full-time! The Hobo Foundation lives on in spirit, but for now this is by far the best arrangement for everyone.

That’s right folks, progress is about to take a big leap forwards. You know what this means don’t you? It means all those warm and fuzzy things like a solid test suite, lots of documentation, continuing to separate out all the major sub-components like DRYML into their own projects. Good things are coming!

I want to say a big thank-you to the folk at Barquin for supporting open-source and creating this great opportunity for the Hobo project. Barquin does a lot of work for the US Federal Government, and to be honest, this is the very last place I would have looked for a company willing to stick their neck out for some exciting new technology. It turns out Barquin are not your average government contractor. They’re firm believers in client-centred agile practices, and that approach recently won them (shameless sponsor plug!) the “Small Business Contractor of the Year Award” from the US Department of Agriculture.

Here’s looking forward to really getting stuck in and making Hobo as good as it can be. Maybe I’ll even find time to blog more :-)

(p.s. In fact I’ve got a whole load more to tell everyone about, so do expect more posts over the next few days.)

So I threw together some simple experiments, and turned on logging in the console. It’s a bit rough and certainly not exhaustive, but I formatted it in markdown out of habit and then though hey, I should post this, so here it is.

Is this stuff documented somewhere? I never found it if it is. I wonder if most Rails devs know about all this already.

This is all in Rail 2.0.2 BTW.

Some simple models

class Post < ActiveRecord::Base
  has_many :comments
  has_many :categorisations
  has_many :categories, :through => :categorisations
end

class Comment < ActiveRecord::Base
  belongs_to :post
end

class Category < ActiveRecord::Base
  has_many :categorisations
end

class Categorisation < ActiveRecord::Base
  belongs_to :post
  belongs_to :category
end

has_many (not through)

Assigning to the array on a new record

New comments are created along with a new post:

>> p = Post.new
=> #<Post id: nil>
>> p.comments = [Comment.new]
=> [#<Comment id: nil, post_id: nil>]
>> p.save
  Post Create (0.000601)   INSERT INTO posts VALUES(NULL)
  Comment Create (0.000195)   INSERT INTO comments ("post_id") VALUES(1)
=> true

Appending to the array

For a post that exists, the appended comments are created immediately:

>> p
=> #<Post id: 1>
>> p.comments << Comment.new
  Comment Create (0.000481)   INSERT INTO comments ("post_id") VALUES(1)
=> [#<Comment id: 1, post_id: 1>, #<Comment id: 2, post_id: 1>]

Assigning to the array on an existing record

Comments no longer in the array have their foreign_key set to NULL. (I’d guess this changes if you declare :dependent => :destroy, but I didn’t try it)

>> p.comments
=> [#<Comment id: 1, post_id: 1>, #<Comment id: 2, post_id: 1>]
>> p.comments = []
  Comment Update (0.001335)   UPDATE comments SET post_id = NULL WHERE (post_id = 1 AND id IN (1,2))
=> []

New comments in the array are created immediately:

>> p.comments = [Comment.new]
  Comment Create (0.000504)   INSERT INTO comments ("post_id") VALUES(1)
=> [#<Comment id: 3, post_id: 1>]

Existing comments have their foreign key set

>> p2 = Post.create
  Post Create (0.000820)   INSERT INTO posts VALUES(NULL)
=> #<Post id: 2>
>> c = p.comments.first
=> #<Comment id: 3, post_id: 1>
>> p2.comments = [c]
  Comment Load (0.000292)   SELECT * FROM comments WHERE (comments.post_id = 2) 
  Comment Update (0.000684)   UPDATE comments SET "post_id" = 2 WHERE "id" = 3
=> [#<Comment id: 3, post_id: 2>]

belongs_to

When assigning c.post on an existing comment, the change is saved when the comment is saved:

>> c.post == p2
=> true
>> c.post = p
=> #<Post id: 1>
>> c.save
  Comment Update (0.000778)   UPDATE comments SET "post_id" = 1 WHERE "id" = 3
=> true

When assigning a c.post to a new post, the post is created when the comment is saved:

>> c
=> #<Comment id: 3, post_id: 1>
>> c.post = Post.new
=> #<Post id: nil>
>> c.save
  Post Create (0.000464)   INSERT INTO posts VALUES(NULL)
  Comment Update (0.000148)   UPDATE comments SET "post_id" = 3 WHERE "id" = 3
=> true

This happens the same way when the comment is new — both are created together:

>> c = Comment.new
=> #<Comment id: nil, post_id: nil>
>> c.post = Post.new
=> #<Post id: nil>
>> c.save
  Post Create (0.000499)   INSERT INTO posts VALUES(NULL)
  Comment Create (0.000161)   INSERT INTO comments ("post_id") VALUES(4)
=> true

has_many :through

Assigning to the array has no effect:

Assignment to p.categories where p is an existing post:

>> p
=> #<Post id: 1>
>> cat = Category.create
  Category Create (0.000427)   INSERT INTO categories VALUES(NULL)
=> #<Category id: 1>
>> p.categories = [cat]
  Category Load (0.000289)   SELECT categories.* FROM categories INNER JOIN categorisations ON categories.id = categorisations.category_id WHERE ((categorisations.post_id = 1)) 
=> [#<Category id: 1>]
>> p.save
=> true

Note there were no changes to the categories table.

Assignment to p.categories where p is a new post:

>> p = Post.new
=> #<Post id: nil>
>> p.categories = [cat]
=> [#<Category id: 1>]
>> p.save
  Post Create (0.000513)   INSERT INTO posts VALUES(NULL)
=> true

Again, nothing happens to the categories table

Appending to the array does have an effect

Can’t append to a has-many-through on a new record:

>> p = Post.new
=> #<Post id: nil>
>> p.categories << cat
ActiveRecord::HasManyThroughCantAssociateNewRecords: Cannot associate new records through 'Post#categorisations' on '#'. Both records must have an id in order to create the has_many :through record associating them.

Can append to a has-many-through on an existing record. The joining record is created immediately:

>> p = Post.find(:first)
  Post Load (0.000365)   SELECT * FROM posts LIMIT 1
=> #<Post id: 1>
>> p.categories
  Category Load (0.000294)   SELECT categories.* FROM categories INNER JOIN categorisations ON categories.id = categorisations.category_id WHERE ((categorisations.post_id = 1)) 
=> []
>> p.categories << cat
  Categorisation Create (0.000479)   INSERT INTO categorisations ("post_id", "category_id") VALUES(1, 1)
=> [#<Category id: 1>]

But this is not allowed if the category is new:

>> p.categories << Category.new
ActiveRecord::HasManyThroughCantAssociateNewRecords: Cannot associate new records through 'Post#categorisations' on '#'. Both records must have an id in order to create the has_many :through record associating them.

Did you learn something?