Pardon me while I geek out again. This particular article falls under the, "look Ma, no hands" category, a shameless play for adoration of my cleverness. What I’m about to show is neither new nor terribly beautiful, nor cost effective for most professional flash designers and/or web designers.

It’s just cool that it was done procedurally and entirely on Linux. First, another caveat; I absolutely do not get these animation tools with their tweening, paths and visual interactions for creation ­of animations. For some reason, when I animate my stupid brain sees a stack of cells, straight up and down. I see the frame changes like a flip book. If I try to­ abstract an object in the animation into some sort of mathematical formula, line, path, or whatever, my little pile of gray matter goes all slushy. Also, my brain likes to see things in text. I know, I know, what’s the matter with me? I don’t even see the code. All I see is blonde, brunette, red-head. Chuckle.

Here’s the finished product: www.og-consulting.com

The door scene modeled in POV-ray scene description language and is typical of Old San Juan, Puerto Rico Spanish Colonial architecture. The real doors are beautiful. If you ever get a chance to take a cruise from/to Puerto Rico, don’t miss the chance to walk around Old San Juan ­(El Viejo San Juan) and check them out. I rendered three frames with the doors rotated from 0 to 75 degrees to simulate… guess what? Opening doors. Clever, huh?

There’s a lot of POV code, here’s a little bit of what it looks like:

cylinder { <0, 0.5, 0>, <0, -0.5, 0>, 0.5
        texture {
        pigment { color rgb <0.6, 0, 0> }
        normal { granite 0.02 turbulence <0.5, 0.9, 0.2> scale 0.25 }
        finish { specular 0.1 reflection .1 }
    }
  }

It’s pretty simple. You place objects in an X-Y-Z space (Cartesian coordinates) like a sphere, cylinder, box or any other of the predefined primitives. You can merge them, subtract them, intersect them in creative ways. Finally, you apply some sort of texture which includes a pigment, a surface (normal), and a finish (reflections effects etc). There are easier ways to model, but sometimes POV-ray’s scene description language is just the most elegant and easiest way to model something.

The next step was to convert the png files to jpegs for inclusion in the flash animation. I used a little sprinkle of bash and a dash of kosher ImageMagick’s convert.

for file in *.png; do convert -quality 100 "$file" "${file%.png}.jpg"; done

For each png file, convert the png file to a 100 percent quality jpeg file. We use 100% quality because I’m going to let the swftools take care of the final compression. There’s no sense in lossy compressing then lossy compressing again. That’s just crazy talk.

We will now create the flash source file. Open a new file slideshow.sc. This is the textual language for the swftools Linux Flash toolkit. I have never ever ever looked at a flash source file from any Macromedia product, so I have no idea if this animation description method looks/acts/walks/talks in anyway shape or form like Macromedia’s products. Don’t know, don’t care.

.flash bbox=640x480 filename="slideshow.swf" version=6 fps=25 compress background=white

  .jpeg s1 "puerta_open03.jpg"
  .jpeg s2 "puerta_open02.jpg"
  .jpeg s3 "puerta_open01.jpg"
  .font font "gilc____.ttf"
  .font arial "arialbi.ttf"
  .text text1 text="Opening Doors" font=font
  .text text2 text="Opening Doors" font=font
  .text text3 text="Opening Doors" font=font
  .text text4 text="OG" font=arial
  .text text5 text="Experts in" font=font
  .text text6 text="Open Source" font=font

  .put s1 scalex=640 scaley=480 alpha=100%
  .put text1 scale=100% x=40 y=220 alpha=0%

  .frame 25
  .put s2 scalex=640 scaley=480 alpha=0%
  .change text1 alpha=100%
  .put text2 scale=100% x=40 y=220

  .frame 100
  .change s2 alpha=0%
  .change text1 alpha=100%
  .change text2 alpha=100%

  .frame 125
  .change text1 alpha=0%
  .change text2 alpha=100%
  .change s2 alpha=100%
  .put s3 scalex=640 scaley=480 alpha=0%
  .put text3 scale=100% x=40 y=220

And so on (that’s not the whole file, but the rest is just repetition. There are 71 total lines of code for that little flash animation. Is that a lot or a little? Seems pretty small to me anyway. Basically, with swftools you define an object (image, or text); you put it; then you change it. You can change its fade, size, location, and more. The swfc program will implement the change from the object’s last known state. Check out swftools for more examples (that’s where I got all the reference I needed to make my little flash thingie).

So there you have it. I walk through the frames, changing elements, putting, fading, growing, moving stuff around. It’s was all described from start to finish in a procedural language, from the POV-ray scene description language, to bash and ImageMagick for command line image manipulation, and finally to swftools flash scene language for the final animation. Pretty nifty, huh?

The neat thing about this is that once the procedure has been developed, you can reuse it for other clients, other looks, colors, messages, etc. In fact, you could directly render it on the server to update information on the fly via end user input. There’s no limit to what you can do with something like this.

Of course if you’re on Windows, you would probably just buy Macromedia’s software… but where’s the fun in that?

Yes, I understand this is going to be a weird post for some of you.  Frankly, I haven’t been writing enough about what I spend most of my day doing, so here it is.

­I have been having a bafflingly hard time trying to figure out the proper way to insert multiple child records from one single webform.  It is the standard fare for posting things like invoice headers and details.  Say for example, you’ve got an invoice record which consists of an order number, date and whatnot.  That particular piece of tabular data is then considered the parent of its child line items (product_id, description, quantity, price, etc).  So you’ve got this Order which consists of an invoice and line items. 

It’s pretty basic, but I’ve had the hardest time figuring out how to do this is Ruby on Rails.  I know it’s not hard in theory, but with Rails, since there is only One Right Way(TM) to do things, ’cause you’re on Rails, it takes a bit of doing to figure out this Right Way(TM).  I personally don’t have a problem doing it Rails’ way, but please dear God, just tell me what it is.  I bought the book and everything.

So here’s the dope, folks.  Please correct me if there’s a better way of doing this, ’cause I’m a Rails n00b.  For reference sake, I am using Ruby on Rails 1.0 with Postgres 8.0.4 and Ruby 1.8.4

First the webform:

<ul id=items>
   <% for item in @items %>
   <li><%= check_box_tag 'line_item', item.id, checked=false, {:name => "line_item[item_id][]", :id => "line_item_id_#{item.id}" }  %><label for="line_item_id_<%= item.id %>"> <%= item.title  %></label></li>
   <% end %>
</ul>

Make sure to use check_box_tag instead of check_box.  check_box holds a hidden text input that by default inserts a 0 into the database.  From http://rubyonrails.org/api/classes/ActionView/Helpers/FormHelper.html

The checked_value defaults to 1 while the
default unchecked_value is set to 0 which is convenient for
boolean values. Usually unchecked checkboxes don’t post anything. We
work around this problem by adding a hidden value with the same name as the
checkbox.

You don’t want that.  You want the plain vanilla check_box_tag which does none of that nonsense, because you in fact, don’t want your line_item table being filled with up with all kinds of line_items referring to product "0" or product "NULL".

So that’s our form.  The line <% for item in @items %> comes from the items.rb model and is just a little database query to get all the items associated with a particular order for posting in our invoice.  Why would we use checkboxes?  Well, maybe we’re not going to invoice the whole order.  Maybe we’re out of some items.  We’ll let our warehouse guy check off the checkboxes on his wireless pda.  How’s that?

If you were watching closely, you’ll notice that I modified the check_box_tag behavior with options of my own with the following:

:name => "line_item[item_id][]"

This is what gives us multiple lines (an array of items) to pass to the controller.  [] is the important part.

Now, so far this is easy, or at least I thought so.  I’ve done this a hundred times in php, but that’s just the problem, I got tired of writing and re-writing this.  I wanted Rails to handle all the parent child relationships for me and leave me alone.  I’m lazy.

But I couldn’t figure out exactly how to do this.  Frankly, I’m still trying to fit all the method/class/object/instance/variable blah blah blah into my head and keep all the Invoice invoice invoices straight.  I know, I know, it’s probably me, but I’ll wager there are a few more slow-witted programmers out there for whom this is all so confusing.  A phrase that I have been becoming more familiar with while working in Ruby on Rails is, "Use the force."  It’s funny, but most of the time when I relax and make stuff up without trying to "understand,"  things usually Just Work(TM).  Jedi Programming… who knew?

So we’ve got our form.  Now we need to post the parent and the children in one fell swoop.

Now for the model (no, not Victoria’s Secret):  Invoice will not reference the children (the children will come running when they hear their parent’s voice regardless of whether they are called by name).  The parent "has_many" children and does not bother remembering their names or ids or anything.  The children on the other hand "belong_to " (or reference) the parent and are tattooed with the parent_id stamp of ownership (big ears for example).   When they are required, they will all line up under the parent and file out like good little children.

Got it?  Parent -> has_many :children, Child -> belongs_to :parent – the model of a perfect Catholic Rails family.

Now we need to post the stuff.  This is a snippet from the invoice_controller.rb:

   def create
      @invoice = Invoice.new(params[:invoice])
      @invoice.order_id = @session["order_id"]
      for item_id in params[:invoice_item][:item_id] do
              @invoice.invoice_items << InvoiceItem.new(:item_id => item_id)
      end
      if @invoice.save
         flash[:notice] = 'Invoice was successfully created.'
         redirect_to :action => 'list'
      else
         render :action => 'new'
      end
   end

order_id is stored in the session array and is used to reference the invoice.  The invoice in turn has items added to it for each item_id in the params passed from our form.  What happens on @invoice.save is the following:

1. Rails inserts the invoice header (the parent)
2. Immediately fetches currval(invoices_id_seq) to retrieve the newly created invoice_id
3. Uses that invoice_id number and iterates over the invoice_items inserting both the item_id and invoice_id
4. commits the results if successful

That’s it!  Easy, huh?  Well it took me all day to figure it out.  I knew it was easy, but perhaps I don’t have mad google sklz or something, because it left me scratching my head.  Hopefully someone will find this useful.  Leave a comment and I’ll do my best to answer your questions.  If not, I’m sure I’ll forget it in a few months and have to reread this *G*.