Flash Remoting.com
Home Book Examples Blog Resources About
Search

You are using an out-of-date browser so the pages will not display properly. Please update your browser.

Random thoughts on Flash Remoting:

This is where I get to ramble when I feel like it. Kind of like a blog, but it's not a blog. This is a blog. ;-).

98 posts.

1/06 | 9/05 | 8/05 | 7/05 | 10/04 | 8/04 | 7/04 | 6/04 | 4/04 | 3/04 | 2/04 | 1/04 | 12/03 | 11/03 | 10/03 | 9/03 | 8/03 | 7/03 | 6/03 | 5/03 | 4/03 | 3/03 | 1/03 | 12/02 | 11/02

Parsing CSV in Flash

Wednesday, December 03, 2003 12:31:54 PM

There was a question on the Flash forum this morning about parsing CSV files in Flash. Obviously, parsing them on the server and returning the results through Flash Remoting would be the ideal situation, but it can be done on the Flash side as well. The following code will parse any CSV file, use the first row of the CSV file as the field names, remove quotes, and populate an array as a data provider. You can then use the result in a data grid or any other way within Flash:

var temp = new LoadVars();
var theFileObj = new LoadVars();
var theFile =
temp.sendAndLoad(" http://mydomain.com/sample2.csv",theFileObj,GET );

theFileObj.onData = function(src) {
  var myDataProvider = new Array();
  // split the file into lines
  // for a UNIX server, use "\n" instead
  var theFileArray = src.split("\r\n");
  // get the first line as field names
  var theFieldNames = theFileArray[0].split(",");
  // Number of fields for counters
  var numberOfFields = theFieldNames.length;
  for(var j=0; j<numberOfFields; j++) {
    // Remove quotes from field names
    theFieldNames[j] = removeQuotes(theFieldNames[j]);
  }
  var tempArray; // set up temp array to hold rows
  var tempObj; // set up temp object to hold new records
  for(var i=1; i<theFileArray.length; i++) { // start at second line
    tempArray = theFileArray[i].split(","); // row from CSV
    tempObj = new Object(); // new record for data provider
    for(var ii=0; ii<numberOfFields; ii++) {
     // put fields from CSV into new record
     tempObj[theFieldNames[ii]] = removeQuotes(tempArray[ii]);
    }
    // add the record to the data provider
    myDataProvider.push(tempObj);
  }
  myGrid.setDataProvider(myDataProvider);
}

function removeQuotes(theString) {
  if(theString.charAt(0) == '"' || theString.charAt(0) == "'") {
    return theString.substr(1, theString.length - 2);
  }else{
    return theString;
  }
}

I tested with a 220K file and the result was parsed and the data grid populated in about two seconds.

Add comment (10)
View comments

Effectiveness of DataGlue

Tuesday, November 18, 2003 11:24:55 PM

DataGlue is one of those things that you either love or hate. Many people have not had much luck using DataGlue, but I use it and think it's a very effective way to populate a UI component. In an attempt to test the effectiveness of DataGlue, I did a simple, non-scientific test of the following:

The recordsets populating the boxes were between 200-400 records each.

Flash MX 2004 Pro -- iterating using addItem()

Testing iteration
Elapsed Time: 94 milliseconds
Testing iteration
Elapsed Time: 109 milliseconds
Testing iteration
Elapsed Time: 47 milliseconds
Testing iteration
Elapsed Time: 94 milliseconds

Flash MX -- DataGlue

Testing DataGlue
Elapsed Time: 16 milliseconds
Testing DataGlue
Elapsed Time: 0 milliseconds
Testing DataGlue
Elapsed Time: 0 milliseconds
Testing DataGlue
Elapsed Time: 0 milliseconds

You can see that DataGlue is a slight favorite here. Still, Flash MX 2004 is not too shabby. It still takes less than a half second to populate 4 combos with a good amount of data.

Then I tested with more records -- between 1800 and 7000 per combo box. This is the result:

Flash MX 2004 Pro -- iterating using addItem()

Testing iteration
Elapsed Time: 1672 milliseconds
Testing iteration
Elapsed Time: 4188 milliseconds
Testing iteration
Elapsed Time: 187 milliseconds
Testing iteration
Elapsed Time: 828 milliseconds

Flash MX -- DataGlue

Testing DataGlue
Elapsed Time: 0 milliseconds
Testing DataGlue
Elapsed Time: 15 milliseconds
Testing DataGlue
Elapsed Time: 0 milliseconds
Testing DataGlue
Elapsed Time: 0 milliseconds

This is where DataGlue really shines. The combo that displayed 7000 records took 4188 milliseconds to fill in Flash MX 2004, vs. 15 milliseconds using DataGlue. DataGlue is effective because it is a simple mapping of the dataProvider fields to the ComboBox data and value properties.

Just out of curiosity, I also tested Flash MX 2004 using the setDataProvider() method and labelField property (as suggested by Nigel in a blog comment) and came up with results similar to DataGlue:

Flash MX 2004 -- labelField

Testing labelField
Elapsed Time: 15 milliseconds
Testing labelField
Elapsed Time: 0 milliseconds
Testing labelField
Elapsed Time: 16 milliseconds
Testing labelField
Elapsed Time: 0 milliseconds

The one disadvantage to this method is that you cannot set the data property this way: only the label property. The use of the ComboBox benefits from the concept of a data element (ID number) and a descriptive label. This allows you to pass an integer value back to your database, rather than a long descriptive string.

For example, if you had 4 ComboBoxes on the screen that were each fed by a different DataProvider as a recordset coming from a server, the field name of the primary key for the database table would have a different name for each ComboBox. For example, a Suppliers table might have a primary key of SupplierID. Using DataGlue, I don' t have to know that--all I need is the data property. Using the labelField property, you would have to know the primary key by name in order to extract it from the dataProvider.

The code used in these timings are the following functions:

Iteration test

function ComboBoxFill(cbName, rs){
  var fields = rs.getColumnNames();
  var tempLength = rs.getLength();
  for(var i=0; i < tempLength; i++) {
    cbName.addItem(
      {label:rs.getItemAt(i)[fields[1]],
        data:rs.getItemAt(i)[fields[0]]});
  }
}

DataGlue test

function ComboBoxFill(cbName, rs){
  var fields = rs.getColumnNames();
  var idField = '#' + fields[0] + '#';
  var descField = '#' + fields[1] + '#';
  DataGlue.bindFormatStrings(cbName, rs, descField, idField);
}

labelField test:

function ComboBoxFill(cbName, rs){
  var fields = rs.getColumnNames();
  cbName.dataProvider = rs;
  cbName.labelField = fields[1];
}

Add comment (5)
View comments

Nobody expects the Spanish Inquisition. ;-)

Monday, November 17, 2003 1:04:37 PM

Nigel Pegg has a new blog, and he has put it to use to give a rebuttal to my OOP Sacrilege article that appeared a few weeks ago. Nigel is one of the top developers over at Macromedia, and one of the top minds behind the component architecture in Flash. Let me preface this by saying that I have the utmost respect for Nigel and did not direct the original article at him or at any other developers at Macromedia. My arguments with Macromedia are mostly aimed at the marketing-driven mentality of the company in general. It seems that they operate more like a television studio than a software company.

The Data Connection kit is a prime example. It was put out in May of 2003, and discontinued in August. In May, it was being promoted heavily. It was given away to Team Macromedia members in the hopes that they would promote it, and being pushed in a big way by the blog marketing machine at MM. 3 months later, the rug was pulled out and any developer using the DCK was left flat on his back. At the time it was released, I was in the middle of the final editing stages of the book. At the time, I had considered holding up production so I could include a chapter on the DCK, because all the hype at MM indicated that it was the best way to connect to data. I decided against it, and simply included a paragraph on it. In retrospect, it was the right decision.

The OOP Sacrilege article takes aim at this type of mentality. The type of mentality that says "lets try this, and if it doesn't work, pull the plug and try something new." The same type of mentality that you see on network TV when a show debuts, is promoted heavily, and is then s***-canned after a few episodes. Generator is another prime example. What is it? Well, if you were around about 3 years ago, it was touted as the future of Macromedia. At least that is what the hype said. Any developer who bought into this was quickly disappointed, like being left in the middle of the lake with a rowboat without an oar. Now we have Flex, formerly Royale. Will it be around in the future? Only time will tell.

Unfortunately, software developers and web developers cannot simply get up from in front of a canceled software program to use a new program. Simply put, a developer spends time learning a technology, and time implementing it. When the plug is pulled, the time spent learning and implementing the technology was wasted, and could have been better spent using another technology. This is why it is necessary to carefully construct an API and set it in stone before putting out a software product. Macromedia's biggest flaw is that they spend too little time in planning. Do we need a new Studio MX every year or would we rather have a Studio MX that is solid, usable, and reliable?

Ok, the new component architecture is here and the thousands of Flash developers now using it are banking on it. If what Nigel says is true, we can count on the API being around for a while. That is really good news.

Nigel addressed a couple of points that need a rebuttal to his rebuttal. First he says:

"... the authoring tool can have property panels which map directly to AS properties - so, say you have the property "label" in the components panel at authoring time, you're guaranteed to have the property "label" at runtime. "

Then:

"I typed this into Flash MX 2004 Professional 2004 MX, with a new checkBox component on stage : "

myCheckBox.setLabel("Muck");
trace(myCheckBox.getLabel()); // traces "Muck"

Ok, this does work. However, if you set the label property with the Component Inspector (which is one of the arguments that Nigel presented: the ability to set properties through inspectors) then the trace statement fails with an "undefined". Does that mean we shouldn't use the Component Inspector to set properties? Chafic mentioned in the comments to the blog entry that we should not be using setLabel() and other private methods. I agree that we should not be using undocumented methods. However, this also makes my case as well: the method was documented in Flash MX originally, and simply left out in the latest documentation. The documentation should clearly state "setLabel() -- deprecated as of Flash MX 2004. Will work in Flash MX 2004 but is not guaranteed to be supported in future versions of Flash." Documentation is everything.

"Tom also brings up the comboBox and "addItem(), addItemAt(), etc". Those certainly didn't change, so I'm not sure where some of this is coming from. "

I actually said that they did not change and that this was a good thing.

"But this brings me to the obvious point about backwards compatibility in the components. The biggest problem with carrying deprecated methods around is that it would have a negative impact on download size. Where it cost nothing in KB, we chose to keep things compatible, but when it came to things like aliasing new functions to old names, we made the difficult choice not too, and hope bandwidth savings would balance the pain to developers. We'd love to have left the old "changeHandler" or styleProperty mechanisms in place to gradually wean users off them, but in the end, it wasn't worth the cost of carrying them around. "

Ok, that is a valid reason, but I'd like to see it documented. If something changed from one version to the next, I would expect the changes to be documented and noted as changed:

columnNames -- replaces the setColumns() method. setColumns() no longer works in Flash MX 2004

setColumns() -- not implemented in Flash MX 2004. Use the columnNames property instead.

I am the first to admit that I'm not a hard-core Flash programmer. I develop in many different languages, and because of that I am surprised when I work with Macromedia's tools and the inconsistencies between versions. Flash is constantly evolving, which is a good thing, but I can only hope that MM is planning for the future when they released Flash MX 2004. Also, with all the effort being put into Flex, let's hope it's not another Generator. We'll know more in a year or two. ;-)

Add comment (7)
View comments

Consistency revisited

Friday, November 14, 2003 3:00:51 PM

I wrote an extension for Dreamweaver a while ago (when DW 6 was in beta) that allowed a developer to get context sensitive help on any keyword within his code. For example, when typing <cfoutput>, you can put your cursor on the cfoutput and right-click > Context Help to pull up the documentation at Livedocs for that particular keyword. The idea behind the extension was to mimic how CF Studio, Homesite, SQL Server Query Analyzer, and other IDEs work, and because the help system in Dreamweaver was so painful to use. I did it mostly for my own benefit, but I also released it for free for the community, and included help references for PHP, CSharp, VB, VBScript, JScript, and HTML.

Wouldn't you know, although the extension still works fine in the latest version of Dreamweaver and most of the help content is still valid (for PHP, CSharp, VB, VBScript, JScript, and HTML), all the help content that relates to ColdFusion is now wrong. Why? Because Macromedia changed the locations and filenames of all of their help content at Livedocs. I know they never promised consistency, but its a shame that they can't keep a simple thing like a URL consistent, especially one that is there to benefit the developer. Do I dare update the extension with new URL locations for Livedocs? I think not.

So, I'll be updating that extension in the near future to allow the user to use local help file content from his own machine, and also update it to work with ActionScript content as well. It's definitely a much needed extension, given the horrible state of the built-in references for Dreamweaver and Flash.

Add comment (1)
View comments

Updated Flash and Devnet

Wednesday, November 12, 2003 1:57:52 PM

Yesterday morning, Macromedia released the first (and hopefully not last) updater for Flash MX 2004. I have not tried the updater yet, but given the extreme buginess of the original release of Flash MX 2004, it can only be an improvement. ;-)

There are no Remoting components in the updater, however they have announced that Remoting is being worked on and converted to ActionScript 2.0: "Macromedia is in a final evaluation process for updating the Flash Remoting components to ActionScript 2.0 and providing other support for Flash Remoting in Flash MX 2004". Check http://www.macromedia.com/devnet/mx/flash/articles/whatsnew_2004_faq.html for more info on the updater.

Also, Macromedia has completely revamped their Devnet center and finally introduced some content that shows the differences between the various data connection methods that you can use with Flash. If you go to the main Flash section of Devnet, at http://www.macromedia.com/devnet/mx/flash/, you'll find some great new content. Click on the Data Integration link for some new content devoted to integrating data with Flash, including info on Remoting.

Also, FINALLY someone at MM has posted information on Flash Remoting promoting it as the best way to integrate data with Flash:

" The data connectivity layer in Flash MX Professional 2004 provides the ability to connect to external data sources to retrieve and send data. This functionality is provided to developers through the WebServiceConnector component for connecting to SOAP web services, the XMLConnector component for connecting to any external data source that returns XML through HTTP (such as JSP, ASP, Servlet, or ColdFusion), and Flash Remoting for accessing data directly from an application server using a more efficient binary protocol."

and

"Access data in the fastest way possible with Flash Remoting. It consumes remote methods exposed by a server using a binary protocol (AMF)."

It's about time the sleeping giant woke up and realized the potential of Flash Remoting over every other method available for transmitting data using Flash. Flash Remoting is, IMHO, the best thing that Macromedia put out in years, and clearly shows a forward-thinking techology that could revolutionize the web if developed and promoted correctly by MM. The web service connectors and XML connectors are OK for light use. Visual data binding is overly hyped and overly complex. It is non-intuitive and clunky to use, and really only saves you from typing one or two lines of ActionScript.

Add comment (2)
View comments

1-5 | 6-10 | 11-15 | 16-20 | 21-25 | 26-30 | 31-35 | 36-40 | 41-45 | 46-50 | 51-55 | 56-60 | 61-65 | 66-70 | 71-75 | 76-80 | 81-85 | 86-90 | 91-95 | 96-98