No not really, LOL I guess I was "starting off easy". Let me try and elucidate (and warning long diatribe possibly coming up). I made the "mistake" (j/k) of calling my brother up the other day to discuss a general concept, basically the VO/Data Classes concept. Well after about an hour and a half of discussion it was pretty much summed up like we were talking about on the prior thread, the "ColdConfusion" thread. Have data classes or recordsets (which as he and I made a very important distinction, have no need to be directly related to the actual underlying data. In other words they don't need to match data existent in a database table. You get the idea)
So now I'm expanding and expounding on that concept. I mean you have a server that holds data needed. This data could be in many forms. What is needed (at least as far as I see it, or am seeing it now) is that an efficient means of passing these "rich" objects needs to exist. We need to be able to pass back and forth "classes" that are understood between the two items. The server applications and the client applications.
So I'm starting off small, with an object of sorts, let's call it a recordset for the time being. And really I guess it kind of reflects back on some earlier posts I made as far as "collections". An array is a collection, and really so is the recordset object we/I am speaking of. Sometimes one type of collection is desirable and sometimes another is desirable.
Clarity and maintainability (and all those other words we hear and sometimes use ourselves) are goals needed for ongoing large projects. So having an understandable (across differing languages, and technologies) object helps provide those things. So I guess in a way that's what I was going for.
Ok I'm blathering here, LOL let me stop myself, and clarify. Taking a narrow viewpoint, let's look at ADO. It provides us (within reason) a means to interact with several different types of data sources. I could have underlying as the source, an Access DB, a MSSQL DB, a FireBird DB, or even a MySQL DB. They would within reason, react similarly. In ADO really all that is needed is to change the "Connect String" and you can deal with the same data existent in either of those aforementioned formats.
LOL Ok that's the way my brain was going. And yes ColdFusion does provide these facilities, and much more. But I was thinking on the basis of "What if I wanted to write my own RemoteObject?" how would one do it? So I was starting off reasonably small, as far as a spec for a RemoteObject. Let's say that you have this Object (this program) sitting on your server. It's initiated by making a RemoteObject declaration in your client MXML code. It's duty is as follows:
1) To take specifications based on the MXML declaration as to what kind of data source it will use, and what the actual "name" of the data source is (or maybe it just notes a UDL and that holds that information)
2) To provide callable functions that return data in meaningful ways. By meaningful mean ints, bools, strings, arrays, and the aforementioned recordset.
So then the two ultimate questions are "How would you call it?" and "How would you implement this called RemoteObject that exists on the server?"
I know that probably clarified a piece and muddied the waters to a large degree. But it is a possibility. ;-)
Thanks Medd,
Christopher
|
Linear Mode
