- see footer for list info -<
instead of passing the individual keys of the segments structure to each cfc that handles those keys, couldn't you just pass the segments structure itself from cfc to cfc and only change/alter/retrieve the keys you need for each cfc?
Or have I misunderstood your problem? On 11/22/06, Steve Powell <[EMAIL PROTECTED]> wrote:
>- see footer for list info -< OK I'm going to hold my hand up right now and admit I didn't think this one through at all before I started. We've got a series of messages that are structured as segments. So one identifies the person, the next identifies their doctor, the next identifies an appointment ect.... Different types of messages have different sets of segments, almost all have a PID (Person IDentifier) and all have an MSH (you can guess what this is). Now I'm sorting these guys into a structure using a CFC. The base CFC has a property that is a structure and this in turn has elements for each of the segments idnetified by the 3 char segment name so I may end up with a struct like this msgObj.SEGMENTS.MSH msgObj.SEGMENTS.PID msgObj.SEGMENTS.DOC msgObj.SEGMENTS.VIS (Appointment\Visit) Each segment is handled by a CFC that basically chops the relevant message string up and assigns the values into a list of more meaningful internal properties. The segment CFC also takes care of serialising the data into a database or constructing a valid string representation from an existing DB entry. Now I want to be able to reference values from PID in VIS and indeed various other bits and pieces as we store all the changes and edits we receive as messages and also store NO-OPS when we receive a PID in one message that's the same as the one we have stored from a previous message. Think about having every version of every entry and a log of every event/message transaction and you're picturing the living hell that is my database design. The way we've done this currently is we pass in a reference to the msgObj.SEGMENTS structure into each of the segment CFC's after we've initialised it. We can't CFDUMP the segments out anymore when we're debugging because of the circular reference and we've had some odd behaviour when reading values form other segment properties inside CFPROCPARAM tags. The same reads work fine if you read the value into a local temp var in the CFC first, I have no idea why. But its becoming increasingly obvious that this is a very bad kludge. What I really want to be able to do is parent child the damn things. I can't see how though, or at least I can't see a cleaner way of doing this using CF. Anyone have any advice/suggestions? There must be a better way. Steve Powell [EMAIL PROTECTED] _______________________________________________ For details on ALL mailing lists and for joining or leaving lists, go to http://list.cfdeveloper.co.uk/mailman/listinfo -- CFDeveloper Sponsors:- >- cfdeveloper Hosting provided by www.cfmxhosting.co.uk -< >- Lists hosted by www.Gradwell.com -< >- CFdeveloper is run by Russ Michaels, feel free to volunteer your help -<
_______________________________________________ For details on ALL mailing lists and for joining or leaving lists, go to http://list.cfdeveloper.co.uk/mailman/listinfo -- CFDeveloper Sponsors:-
- cfdeveloper Hosting provided by www.cfmxhosting.co.uk -< - Lists hosted by www.Gradwell.com -< - CFdeveloper is run by Russ Michaels, feel free to volunteer your help -<
