Open Source Rails & Flex eCommerce Application

17 July, 2007

[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 ? We made the conscious decision that we don't want to sell the application, as such being closed and proprietary we gain no extra business value by keeping it internal (this doesn't preclude the possibility of a hosted version being provided down the road). The application contains no proprietary information to Fastmount Ltd so there is no harm by open sourcing it. Having done a number of eCommerce solutions, the problems faced and solutions tend to be very similar regardless of domain. Thus the app's tend to look very similar. Why reinvent the wheel, over and over again? My personal vision is that a vibrant community will flourish around the application. If it can become an option for people when putting together an eCommerce solution then I would be ecstatic. Currently I haven't seen an active Rails based open source eCommerce engine out there so there's hope that this may become one of many possible standard 'engines' for people to use. Through our background in the widget ordering domain - solving business problems beyond the simple shopping cart such as; multiple price catalogues, multiple currencies, product/ package combination, agents, sales by regions etc - this may help to be a learning tool for those who aren't familiar with the problems at hand, introducing real world solutions beyond your standard learning materials and tutorials. Also by opening it up, and allowing public scrutiny will likely ensure that a higher standard of coding is reached within the application - there's nothing like judgement from your peers to keep those nasty kludges out of the codebase. Why Flex ? Flex, does at first glance seem to be an odd coupling with Rails in terms of philosophical approach. However as a business tool, this application needs to work perfectly, regardless of browser incompatibilities. In my own opinion, the time saved by not having to deal with these issues, along the extra interface richness granted by Flex, warrants the extra upfront time in creating the Flex interface. What should be noted here is this application is more of a business to business, rather than business to consumer type system - thus we can expect less casual browsing/ordering as in the case of a product catalog/ecommerce app versus a very defined business process for ordering. Having said all this, whilst the app has a Flex front end by using some Rails niceties there will be no stopping anyone developing an HTML front end for the app (infact the app will already have some front end work in HTML), so the core Rails application will become the engine and any various front end(s) that may appear can be bolted on. We're using a REST based approach to facilitate this. Roadmap Current Status: Initial development of Order management stories; Creating, editing, listing orders and customers. Evaluating implementing microframeworks for the Flex front end (Cairngorm or Model Glue Flex). Evaluating communication methods (HTTPService, WebOrb, RubyAMF). Release 1: Production ready system - Revamp of existing system in Rails and Flex, all existing user stories maintained. Streamlined order entry system, customer management, order payment processing (via ActiveMerchant), shipment tracking (via UPS). Release 2: Customer Relationship Management enhancements Release 3: Inventory Management, manufacturing enhancements. Community Release The application will be released to the community under an Open Source license (license to be decided), the only caveat from our production system will be licensed assets (such as icons) stripped out for community release with placeholders for people to find their own. I haven't as yet investigated a trac (or trac like system) that's impervious to spam, so for any community members that have any ideas reading this post feel free to drop us a comment. This will likely happen in the next month. Community Contributions We will welcome contributions and commit back into the core, so long as they don't negatively impact core functionality. Process as yet undecided. To ensure fair attribution - the credits page of the app will include your name as a contributor. Whatever license is decided upon will require that any modifications are publicly available as open source. Share and share alike principles. The Name? Undecided - if you want to throw out an idea feel free! Keep Informed All announcements will be made here on this blog. Keep informed, keep your RSS readers locked to http://feeds.feedburner.com/rowanhick In closing I'm personally very excited about providing this to the community and hope good things will come out of it.

Read More

DataGrid - handy hints

25 May, 2007

Okay the orders list. It's a plain vanilla DataGrid component bound to the result from an HTTPService call to get an XML representation of an ActiveRecord orders collection. This all pretty easy to get up and running, but I ran into two immediate snags. Requirement #1 - Multicurrency in the totals column. Our system deals with orders in currencies all over the world, so we have price types and associate each order with a price type. Fair enough. Now we don't store price type symbol with the total (naturally) so how do we get it to appear in the same column in the the datagrid. Option 1 (on the Rails side) would be to add some faux accessor and iterate over the orders populating it before we handed it to the to_xml function sending it to Rails (that's not without it's problems). OR Option 2 (on the Flex side) we manipulate it over here. First off we create a little function that takes our current item (row) and the column we're manipulating, then prepends the symbol and appends the code to the amount.

private function formatCurrency(item:Object, column:DataGridColumn):String
{
   var field:String = column.dataField;
   return item.price_type_dollar_sign+' '+item[field]+' '+item.price_type_symbol;
}

Then in the mxml code for the datagrid

  <mx:DataGridColumn headerText="Total Amount" dataField="total_amount_payable" labelFunction="formatCurrency"/>

Requirement #2 Sorting a field in an order different to that displayed So we have an order status (Draft, Pending Review, Review, Payment Pending, In Manufacturing, Shipped etc). Great, now you put that straight into your datagrid, hit a column header to sort, and realise it's doing an alpha sort on the status name. As you expect (but not as you wanted). Well again there's two ways to accomplish this - one is to pass in custom sort function to figure out the order. OR The other option, is to pipe down in your xml along with the order status name, a sort order numeric value , so Draft is 1 Shipped is 1000, everything in between gets a number etc. Then just as you do for the currency symbol, change the formatting of the column - so we bind our column to the order status sort_order value, but we display the order status name. When the datagrid sorts, it sorts on the bound value, not on the formatted value. Very nifty and simple. Just like this...

private function formatStatus(item:Object, column:DataGridColumn):String
{
    return item.order_status_name;
}

  <mx:DataGridColumn headerText="Status" dataField="order_status_id" labelFunction="formatStatus"/>

No nasty sort function, and does the trick. That's it for now... till next time.

Read More

Possibilities become real.

23 May, 2007

A while back, at a previous company, our clients inundated us with feature requests. At one point at the infancy of this software's life, the codeword for "thank you for your request, we'll try to get it into the software" was called Possibilities. It always left the door open, however I'm sure the rate at things went through the door and never came back (well not until years later!) possibilities became a dreaded word... Now however (my personal belief) is between Rails and Flex turning the seemingly impossible to implement round in no time at all. After a rocky road start to Flex, I'm now having the opportunity to develop a full blown B2B application in it. Replacing a PHP/HTML solution. Both exciting and nerve racking - last night a good 2 hours was spent tracking down how exactly to get something shown in the correct order. I am well impressed, and looking forward to the future of possibilities with Flex 2, Apollo (and what Flex 3 may bring). To share my enthusiasm a good portion of this blog is going to be dedicated to documenting the rebuild of the previously mentioned B2B application. Currently I have client buy in, after ~ 6 hours of knocking up simple interface showing off a very 'windows like' application within a web browser he's sold on it, so it's now the big re-write. Here's the starting point for it: - A rails app with database migrations to take the v1 app's database and migrate it into a rails friendly naming scheme. - Basic objects replicating core functionality within Rails - Two flex front ends, one for general order management, and the other a tailored interface specifically for manufacturing. So far, here's my pro's and con's list Pro + It's going to work once, anywhere. Flash bugs cross browser are fee and far between. (compare that with XHTML/CSS/JS) + More native application functionality (drag/drop, grids etc) + Less network traffic per session + More responsive application Cons - Write, compile, write, compile, write, compile (although Flex Builder/Flex compiler shell reduces the pain) - A lot more code in building the interface - Guess work figureing out how to do complex stuff - Loosing some of Rails niceties (or duplication of things like validations) Next up some screenshots....

Read More