One chasm between traditional desktop application development and web application development is layout/forms design. It’s my constant pain point “I just want a 2 column layout, with a data table in the middle” - many hours later you’re still tearing your hair out trying to get it working. It should not be this way (and that’s just for prototyping).

To get a production tested basic grid/column based layout, that looks reasonable across all browsers and is flexible enough to grow as the app grows - well we all know how much a top notch HTML/CSS wizard is going to cost us right ? Why for every project the same ground of IE hacks and cross browser issues are solved over and over again ? This is half the reason that a sandbox environment like AIR is very appealing - don’t deal with it, just get your users to use a standard environment.

Enter from stage left, in the why hasn’t anyone thought about it before category, are two CSS frameworks that I happened upon on Friday. One called Blueprint which is getting a bit of attention, and one with the rather confusing name of YAML. After seeing all of the examples of YAML, and reviewing the documentation I thought what the heck lets give this a go.

More work on XChain. In some spare hours on the weekend I implemented the basic structure of price catalogues for products. I can’t tell you how long this took when previously doing it in PHP a few years back! (or even worse ASP a few years further back still). I’m sold on BDD, it was so quick to bang this out starting with the spec it first approach, mainly because all you need to do is ‘rake spec’, and bingo your code is tested…

As follows, note code is cut down a little, but you get the picture:

# A product itself does not contain any price information, it has many price's in a 'pricing' model, that is linked
# to price types, eg "Standard Distributor" "Standard Retail"
class Product < ActiveRecord::Base
  has_many :pricings
  has_many :price_types, :through => :pricings
  belongs_to :order_line
end
 
#The pricing table, not only links to a product and price_type, it also has a discount
#model associated with it..
class Pricing < ActiveRecord::Base
  set_table_name 'pricing'
  belongs_to :product
  belongs_to :price_type
  belongs_to :discount
end

Whilst I wait to sort out the UI issues I’m building up the specs’ for XChain. I’m using RSpec, so it’s a lot more ’self documenting’ about what you can expect the application to do. Starting on a fresh project, it’s immensely enjoyable to get into the spec -> code -> test -> repeat cycle. If you’re at all hesitant about getting into them feel free to go browse the source of my specs. I only spent a little time on it last night but already starting to see progress - a lot of the schema is getting cleaned up as a result of the specs. Here’s the doc out put so far (which is about a fraction of what the finished specs will look like !).

Order when creating a new order
- should be able to instantiate
- should default to draft status
- should be able to prefill an address
- should have a default price type matching customer price type
- should calculate return 0 dollars
- should throw an error that it doesn't have line items
- should be able to be edited
- should be able to have an order line added

Order when finding existing order
- should have id = 1
- should have a purchase order number
- should have 3 order lines
- should have a billing address
- should have a customer

To get the specs running.

Following on from my post yesterday, I’m asking the question to the community, how big can Flex apps get. This is probably the great unknown which makes it hard (on this project) to commit to Flex. I’m not sure if I’m going to get halfway in and strike performance problems or such like (this is just conjecture!). HTML it’s easy, it doesn’t matter how big the app gets you’re always just firing down a single page to the browser - you just have to manage page load times, this (for myself, and I guess anyone getting into Flex) is a little unknown. The questions are

1) Am I crazy trying to develop 1 person ~15hrs a week, given the apps functional list below, over ~6 months
2) Whats a good example app close to this size.
3) What kind of performance impact (if any) is there in adding each new functional area

The old simple triangle of time vs features vs quality has reared it’s ugly head again. After one particularly unproductive weekend I’ve made the decision to place a hold on the Flex interface for XChain, in favour of a raw HTML interface, sprinkled with AJAX.

I personally hate the decision, being enamored with Flex, I don’t want to make it, but I look at the forward progress I’ve made in the past couple of weeks and it’s been more or less stationary. I’m not trying to deliver the ‘richest’ interface possible, I’m going to deliver a working application.

What impacts my client most, is that they can get their job done.

The open source Rails/Flex eCommerce application now has a name - XChain - pronounced cross-chain. I had some air travel time over the weekend and put it to good use coming up with a name, the basic premise being that the app should really be classified as a Supply Chain Management system as it deals with a lot more than simply taking peoples money for a product. (Order fulfillment, shipment tracking, eventually CRM and inventory management), and being a cross of two major technologies it seems to fit. Catchy enough and has meaning. Well I think so anyway, others might disagree - (that’s what the comments form at the bottom is for…), only downer is XChain.com is taken by some spammer, but I’ve snapped up .ca and other appropriate domains.

[Announcement] Rowan Hick Consulting, Canada and Ron Hanley of Fastmount LTD, New Zealand are pleased to annouce that their new Rails/Flex/MySQL eCommerce application will be released to the community under an Open Source license. The application, is a successor to a PHP/MySQL based application developed by Rowan Hick and James McGlinn of Nerdsinc Ltd New Zealand.

After nearly 2 years in production, with the advent of Rails, Flex, and the rapidly growing business needs of Fastmount, the current application no longer meets the business needs of Fastmount. We made the decision early this year to re-write a new application and have been developing requirements for the application as well as evaluating technologies.

The application is a business to business eCommerce system. Allowing a marine manufacturing company in New Zealand to service it’s agents, distributors and customers world wide. The existing application facilitates order management from creation through to shipping tracking, along with customer management and some reporting elements.

Why are we open sourcing ?