I'm done with my simplified CF YODEL parser. Here's the YODEL information:
http://www.depressedpress.com/Content/Development/YODEL/Index.cfm What I'm stuck on is the generation/passing of metadata. I'd like to have my generalized parser be able to, at least for queries, generate metadata automatically. The metadata consists of the datatype of the query cell or column ("object", "array", "null", "undefined", "string", "number", "boolean", "date", or "binary"). It would also be nice if I could generate such data for structs and arrays as well. For example if I had an array with three columns (a numeric, a string, and a boolean) I would want to store/link to it something like: "YODEL_Fields=number,string,boolean". Or, better yet, store something like: "YODEL_MetaDataName=MyArray;YODEL_MetaDataFields=number,string,boolean" someplace and then, linked to the array store: "YODEL_MetaData=MyArray" (thus allowing me to reuse metadata for many objects if needed). My original, too simplistic, thought was to automatically generate the metadata by looking at the data... but this is pretty much unworkable. Secondly I thought about adding properties, in some way, to the objects... but I couldn't discover anyway to do this. Even if I could I would rather not have to change the data to support it (the data should stay the same). So... I'm currently playing with the idea of creating a hash table of metadata information. Here's some brainstorming: 1) I could link a reference to the object to the predefined-meta data. I might do this is a hash table like this <cfset MetaData[MyQuery] = DefinedMetaData /> This might work... but it would need to be done for every object that I wanted to apply metadata to - which might be a lot). Since arrays aren't passed by reference I don't think I could do the same thing for them however. 2) I might defined some kind of "object signature" and link it to that. For example this <cfset MetaData[MyQuery.columnlist] = DefinedMetaData /> would let me link all queries with the same column list to the defined meta data. I could something similar to structs (using the key lists). I don't see any easy way to apply this to arrays however... but that's an acceptable loss I think. However this would require that all objects in the parse operation have a unique "signature". Is this a bad thing? Do you often see queries or structs with the same column-/key-lists which have different data types contained in them? Is there any way to reasonably do the same for arrays? I had also considered taking a hash of the "toString()" method and using that as the ID... but I think this would be slow with very large objects and no unique enough with very small ones (although perhaps not... opinions?) It would also be nice to do all of this in "standard" CFML rather than digging down into Java. 3) I've also considered a post processor solution. In effect this would parse the YODEL packet "normally" (perhaps resulting in a very large packet). It would then accept metadata "filters" to be applied to it. For example if I passed in a filter defined as: Name="MyObject" Type="object" Fields="LastName,Age,Married" FieldTypes="string,number,boolean" It might generate the following meta data and add it to the top of packet: <md name="MyObject"> <d type="Object" fields="LastName,Age,Married"> <d type="string" /> <d type="number" /> <d type="boolean" /> </d> </md> Finally it would create a regular expression from the metadata and replace all matching instances of the object with the metadata. So it would find this: <d type="Object" fields="LastName,Age,Married"> <d type="string">Davis</d> <d type="number">34</d> <d type="Boolean">true</d> </d> And replace it with: <d metadata="MyObject"> <d>Davis</d> <d>34</d> <d>true</d> </d> My only real concern here (besides parsing performance) is that the initial datatype recognition would have to be VERY good for this to work. The string "true" or the number "1" could never be mistaken for a Boolean for example or the matching would be off. I guess in the end I'm looking for a way to, without altering the data, provide optional "type hints" to CF data. Any thoughts? Did I make any sense at all? ;^) Thanks, Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:219193 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
