10:37:44 AM
3GH0MS7W6
oInvoice aLineItems aRow[1]
First of all, I know I'm about 7 or so years late to this discussion, but I'd really like to know, why use arrays to hold the children and not a collection? Now, if I had to guess, I'd say that it's because the "FOR EACH enumeration of VFP Collections does not provide true object references":
http://www.west-wind.com/wwthreads/ShowMsg.wwt?MsgId=0Y40USMEN
_and_ because VFP arrays are so much more feature rich than VFP Collections, like using SCATTER and such. So is that the gist of it, or is there something else?
I've just been doing a lot of ASP.NET MVC stuff lately and while reworking some circa 1999 code thought I'd make it more object driven and immediately ran into this.
Also, speaking of Business Object stuff, how do you normally deal with needing to have those children ordered? For example, suppose you've got a Business Object oCart that has an array of oCartItems that's being added to by the user. But, because of group discounting at say a Category level, you need to display those cart items grouped by Category instead of natural order. Which of course might require resorting for every add. Do you make your array more heavyweight, deal with it display side, or is there some simple solution that I'm missing (like 90% of the questions I ask here <g>). Actually, as I typed this, I realized I'd be persisting to data for every hit so I'd be loading fresh each time but I'm still curious about this. I'm sure there are situations where you need to have those children ordered differently, or no?
~Brett
