DataProvider Metamorphisis: A Parasite That’s Straight Jacked

I don’t read much. From disregarding instruction books on my Nintendo games to only touching the new <a href=””>DevNet</a> articles when I want confirmation in my hard won beliefs. I feel I learn better through doing.

So, I figured I’d give the DataProvider a try with the new components in F-two-Fo (F24/Flash 2004). I breifly scanned over the intructions as I couldn’t get a simple List to update with my DataProvider’s information. I liked the simple way of setting it’s property to the DataProvider instance, but… it still didn’t work. Since they documented modelChanged, I thought maybe I had to broadcast it myself, or maybe subscribe the List as a event listener manually; no dice. After actually reading, it seemed I was doing everything correctly.

So, I naturally asked <a href=””>Erik</a>; if I can’t figure something out, and still can’t after actually RTFM, Erik is my first choice of help. After discussing last night’s <a href=””>DoD</a> excursions while Erik pounded away, he reached the same point of “wtf” that I did. The file was kind of whack too.

Erik kept mentioning that he read and interpreted the docs as saying the DataProvider was nothing but an API; basically just an interface not actually holding any data (because the Array’s worked). I then re-read the 2nd paragraph if the List’s dataProvider description (I think that’s where it was). It turns out that the DataProvider simply extends the Array’s prototype so all Array’s now have the DataProvider methods (addItem, removeItem, etc). We tried it and it worked.

Why does weird shiot always happen on Friday’s?

So, in conclusion, DataProvider used to be a class in which to hold all of your data. Now, it’s just a (don’t know the pattern name) an API that’s added to Array’s. So you create an array, but use the DataProvider methods on that array.

Uh, yeah. If this is already covered on DevNet, whoop-pu-dee-dooooooooo…

4 Replies to “DataProvider Metamorphisis: A Parasite That’s Straight Jacked”

  1. I’m not as down with the street as I once was, but was this a positive post or negative? Anything we could be doing better?

  2. Well, keep in mind I’m still learning.

    I think Erik’s worries where that since your doing the prototype, although this is efficient, your now empowering all Array’s with this ability. What he keeps touting to me is that prototype is dead (for good practice anyway), and your supposed to be rolling your own class that extends another one.

    This seems to spit in the face of that, so I guess if DataProvider extended Array instead of messing with the prototype, that’d be cool.

    I do like, however, how I can just an array; that’s pretty conveinant for a dataprovider.

  3. Actually, the issue really was the docs didn’t seem to make this clear. This was partially due to me using DataProvider in the past as it’s own class, not just an interface/API type deal, so that added to confusion of understanding that I should use an Array, but just “trust” that it’ll really be a DataProvider.

  4. It’s a decorator according to the comments however a decorator must conform to the interface of the object it is decorating (See GOF Design Patterns Page 179 Implementation). In this case it does not. It is adding public methods to every instance of an existing class. You should never touch a class that doesn?t belong to you.

    I?d much rather use an instance of the dataProvider class then have my array (err all my arrays) magically turn into one.

    I like the concept but not the implementation.

Comments are closed.