Flash Shop

This article is not finished and a lot of cleanup.

Spreadshirt implemented a shop in Flash as an example of how their web services could be used. Their developer site is being revamped at the moment so I've released it myself on google code and, since it's licensed under the BSD license, it's free to download. If you tried in the past to download the version from the official developer site, and found you couldn't get it to work, then try this. I've made some bug fixes and modifications so it should be usable on any hosting running PHP 5. You'll also need the Flash IDE if you want to use it with your shop (but you knew that anyway ) This section details the problems encountered, how I fixed them and will also document how it works so you can get a headstart if you want to modify it. Ultimately this is intended as an example, not as a finished solution and therefore still has room for improvement. So please take it, improve it, and then submit back your improvements so that everyone can benefit.

• Flash 8 - (With knowledge of Flash it could be ported back to Flash MX 2004 (Flash Player 6). I'm sticking with Flash 8 for now.)
• A server with PHP 5 - this is needed to run a proxy script which is explained below. The Flash shop and the PHP script have to reside on the same domain e.g. www.mydomain.com (No database is required.) (The PHP script could be ported back to work on PHP 4 with the NuSOAP library but since PHP 4 has been discontinued and it's so much easier in PHP 5, I won't be doing it any time soon, if ever.)
• If your server is Windows you may have to do a little more configuration since the script uses the CURL library, which isn't installed by default, AFAIK. See the PHP manual page on the subject.

The Flash shop uses an industry standard software architecture pattern known as Model-View-Controller or MVC. Building it this way makes it reasonably easy to change the user interface (View) without changing how the shop interacts with the Model (in this case accessed through a web service) and vice versa. In fact, Spreadshirt intends you to change the user interface. The model classes are in the package (folder) net.spreadshirt.shop, the view is in net.spreadshirt.view and also in com.yourdomain.spreadshirt.gui package and the controller class is in the net.spreadshirt.controller package. There are also two other packages of classes: net.spreadshop.logger and net.spreadshop.util. The logger package provides logging and debugging functionality and we will discuss the util package further later.

For most developers it may be enough to understand the View section so that they can provide their own unique user experience.

[To be written]

[To be written]

[To be written]

[Summary to be written]

This is a current problem with the get_articles method of the service. “image_url” properties are being returned prepended with the spreadshirt URL.

The get_producttypes web service method wasn't working. I simply reported this to Spreadshirt and they repaired it. There are still a couple of major problems with it however as of 2008/06/02.

• The results are always returned in German regardless of what the session locale is set to.
• The search_phrase parameter doesn't work - it always returns everything.
• If you send a limit parameter without a position parameter the service returns a 500 (internal server error) code from Apache.

Proxy Suggest replacing services for AMF / JSON

Replace urls to match proxy

Parsing without checking element / attribute name - can't have an expectation of the order of elements (true? node order probably not redundant)

The WebServices object seemed to have trouble parsing the returned XML for some reason. Either the class can't process the XML, i.e. there is an error in it (or the class is a limited implementation), or there is an error in some of the XML returned. See Parsing issues below for more details. As a work around I decided to parse the XML myself:

• I set the doDecoding property of the SOAPCall object to false to get back the raw XML
• I passed the raw XML to a new XML object
• I wrote my own parsing function using XPath.

The method at the bottom - getNodeValues - would probably work if the XML was being parsed correctly.

You only need to read this next part if you're really interested in fixing this problem with Flash

Decoding SOAP responses in Flash is handled by the PendingCall class. The class is having trouble decoding maps from XML into the Flash equivalent which are associative array objects. From placing trace statements along the way, I noted that the decodeMap function is never even reached. Working back from there, the function that calls decodeMap is called decodeResultNode. It makes the decision how to decode a node based on the value of schemaType.typeType. This was undefined. I'm not sure if it should have had a value at this point or not. However, if it doesn't, it calls getTypeFromNode to find out the type by reading the value of the xsi:type attribute. By tracing the value of node in this function I noticed that the node starts with an <item> element which, of course, has no xsi:type attribute. So it appears that Flash is not expecting to find everything encapsulated in <item> elements. I don't know enough about XML to know if that element is required or not but it makes sense. This implies that it's a Flash issue so I decided it would be better to decode the XML myself rather than try to bug fix Flash 8's services classes.

        <basketitems xsi:type="ns2:Map">
          <item> <------<<< Node object starts with this element and Flash seems to be choking on this node. 
            <key xsi:type="xsd:int">6701731</key>
            <value xsi:type="SOAP-ENC:Struct">
              <basketitem_id xsi:type="xsd:string">6701731</basketitem_id>
              <article_id xsi:type="xsd:string">5421915</article_id>
              <product_id xsi:type="xsd:string">6127007</product_id>
              ... more elements ...
            </value>
          </item>
          <item>
            <key xsi:type="xsd:int">6701678</key>
            ...

There was a minor bug in the getBasket method of the Services class, each item in the basket had a currency property. The get_basket server response doesn't have a currency property for every item. The currency is just set generally for the basket.

The shop agrees with the spec which says a gross_coupon property should be returned. However, for the get_basket function, the server actually returns a gross_coupon_basket and agross_coupon_shipping property but no gross_coupon property.

• Currency values calulated on the client side are not being rounded to two decimal places.
• Currencies are not being displayed with localisations e.g. In English speaking countries we have €1,500.99 whereas in Germany it would be written as 1.500,99€.

The TnC text box doesn't displaying anything up to the 4th section of the text or anything beyond section 2 of the 11th section.

This isn't actually done yet but I do intend on doing it.

The fla files which make up the GUI use Flash components such as buttons and selection lists. They often make use of the same Flash components but, each file had its own copy of the component which makes the application unnecessarily large. I have will combine all of those components into a single shared library.

Here's a list of potential improvements that occurred to me as I investigated Spreadshirt's Flash shop.

1. Convert to HTML (& AJAX): Although technically interesting, it's doubtful that Flash actually adds much to the user experience in this case. It would certainly be possible to implement a similar shop using html and a server side SOAP library such as PHP's native library. That could be combined with a javascript library such as Prototype, jQuery or MooTools to provide an AJAX solution that could be comparable if not better, especially in terms of accessibility and SEO. Both of these issues are particularly relevant in e-commerce and are typically hard to cater for in Flash.

2. Convert to JSON: The amount of XML data being passed back and forth can be quite large if you have a good number of t-shirts / product types / designs in your shop. Since a server-side script is needed anyway, it seems that it might be more efficient to convert the requests and responses to a more light-weight format such as AMF or JSON. JSON would be particularly nice as it would make it relatively easy then to implement the shop with AJAX as well as, or instead of in Flash. See this article about converting XML to JSON

3. Component based approach: I haven't looked into this in depth, but it seems to me that much of the complexity of the Flash shop could be avoided by using the WebServiceConnector component. It would also save some time for the user because, when the the developer uses the component, the 32KB WSDL file (which defines the service) is downloaded only into the IDE to help the developer write accurate code and not during runtime. 32KB is a significant bandwidth saving. A component based approach in general may have made the shop easier to understand to anyone hoping to customise it. But again, I haven't looked at this option in any detail and, therefore, I don't know how capable the component is.

4. Localisation: This Flash shop's interface is hard coded in German in the GUI classes. An autmatically localising version would be nice although this shop is really only a proof of concept. Realistically, you should discard the GUI and make a new one to match the style of the website you currently have and to differentiate from other sites using this application.

5. Interface issues:

• There's no button to simply bring up the cart had one dismissed it earlier and then decided that one would like to check out.

• Drag and drop ability would be nice.

• Deleting items from the basket is quite confusing for the user.

6. Error handling: Dealing with networks and data from an external source is often prone to errors. It would be nice to see some more robust error handling.