A couple of things to look into: - Dictionary class (basically a hash in object form) - use dynamic/public [Bindable] vars for things like data providers that you can set based on whatever fields are appropriate - write a solid xml/config reader that can map an xml description based on the 'actual' db structure to the 'necessary' field structure used for display/UI - use this xml to bridge your CF and Flex VO's - in flex you can always reference a field on some generic object by using hasOwnProperty(propName) and obj[propName]
On Tue, Mar 2, 2010 at 2:33 PM, Charlie Hubbard <[email protected]>wrote: > Lawerence, > > Welcome to the wonderful field of software development. And the reason we > get paid to do this stuff. > > There's nothing you can do about this problem other than modify your > program, create upgrade paths to migrate data, and put versioning in your > product to help aid in this. This is state of the art advice here, and > everyone does it. That's the short answer. > > The longer answer involves why you can't build a system that modifies > itself and runtime to accommodate new data you weren't anticipating (without > some very real trade offs). Let's say you did have a VO that could > dynamically adjust itself to the database. Great now what is your UI going > to do with it? Or what would the rest of the program do with it? When it > was built it had no knowledge of this format. What if you had a first > name/last name in separate fields then you combined them into one field. > But, your UI is still asking for them separately. What then? Does that > mean your UI can adjust itself too? The short answer there is nope. It > can't. And the developer can't write code to anticipate these types of > changes in a general fashion so that any potential change could take shape. > > What this means is whenever someone wants to change the way the software > works you need to treat that as a new version of the product. Create an > upgrade strategy to upgrade the old data to the new format, upgrade any > clients you might have (with Flex and AIR that's pretty easy as deploying a > new SWF to the server, and all clients will get it). And, now you're off an > running with the new version. > > If you have one particular area that requires a lot of changes then I agree > with Cameron sounds like a requirements issue. You might be able to come up > with a design that can modify itself or be dynamic in limited situations. > For example, the use of metadata in a general sense, can help alleviate > customers that require custom data fields. So generalizing metadata on > objects can help with this, but you'll find it's not easy to code special > behavior around a generalized structure like metadata. Metadata might be > something as easy as a series of Strings keys to String values. And the > user can populate these string->string mappings through some XML. However, > when you start needing key X to be a number, and key Y to be a date it > starts getting very tricky. Next you'll find yourself building a typing > system that describes which properties are number types and which properties > are dates, etc. You can start to see how going generalized has a very > serious overhead required. As the problem gets more complicated more > generalized structures have to be introduced to describe data and describe > behavior of data. Every time you do this you edge yourself closer and > closer to something that requires the level of programming your generic > system. > > Other ideas here are the use of Plugins. Small snippets that can be added > by the user to augment the system in some way. Plugins give you the control > you might need, but they come with a big cost. You have to program them, > and develop an API they can use to interact with the system. And, you can't > avoid the versioning problem here either. A plugin written to work with the > older system might be broken by changes you make to the new system. It's > not impossible to keep things working, but it's more work and more > responsibility you as the software developer have to maintain. > > Generalized programming like this is powerful and flexible, but it requires > giving up some control (whether that be behavior or functionality in the > core system) and possibly loads maintenance work to maintain systems like > these. In the end sometimes it's easier to be specific than to be ever > flexible and generalized. You have to make trade offs between them to make > the system usable and flexible to fit the user's needs. > > Charlie > > On Tue, Mar 2, 2010 at 4:12 PM, Laurence MacNeill > <[email protected]>wrote: > >> Is there anyone in this group who's an expert on both Flex3.5a and >> ColdFusion 9 that I could "buy" for a few hours? >> >> I'm extremely confused on this particular problem I'm having, and I just >> can't find the solution on the web. At least, not a solution I can >> understand... So I'd be willing to pay someone for their expertise... But >> it's gotta be true expertise - not a situation like "sure I'll take your >> money and give you what help I can..." I need guarantees here... The >> problem gets solved or you don't get paid -- that kind of thing. >> >> So if you're truly an expert in Flex 3.5a and ColdFusion 9 (both, not one >> or the other), then I really want to negotiate a per-hour rate with you for >> some one-on-one help... >> >> Or, perhaps someone knows of a solution to this that can be found in the >> (literally) millions of flex blog-posts on the Web... And I'm just not >> searching correctly for it... >> >> The problem I'm having is that I've written my program with Value Objects, >> in order to easily pass data between my Flex App and the ColdFusion >> back-end. (And to pass data between the various modules within the Flex app >> as well, of course.) >> >> This works great. Until a client says "Hey, we want to store THIS instead >> of THAT data..." Then the clent's database has to be modified, the .AS and >> .CFC files that define the structure of the VOs have to be modified, all the >> references to the VOs in the code have to be modified, and the entire >> program has to be re-compiled into a new .SWF file. Then, of course, we >> have to be very careful to use the correct version of the program on that >> client's data, and no other clients' data... We wind up with 500 versions >> of the program floating around. VERY bad solution... >> >> From reading a few blog posts I can find, it does seem like there is a way >> to create dynamic VOs based on the fields in the database. At least in >> Flex, it seems possible. I haven't found a way to do it with CF... I've >> only found a way to do it with something called LINQ, and that apparently >> only works when you're using .NET 3.5 as your back-end? >> >> So all of this raises many questions for me: >> >> 1) How do I tell my Value Object what fields we've added to or changed in >> the database without re-writing the entire VO (in both the .AS and .CFC >> files) and re-compiling my program? In other words, I need a dynamic VO >> that changes automatically with the database. >> >> 2) If there is a way to dynamically create a VO in Flex (and from a few >> blog posts I've seen, it seems there is a way), how do I tell CF9 what the >> structure of that dynamically-created VO is? >> >> 3) How do I reference the dynamically-created fields in my Flex program? >> Right now, for example, I can define a variable called attendeeInfo as type >> attendeeInfoVO, and then reference things like attendeeInfo.first_name, >> attendeeInfo.last_name, etc... How do I reference a field programmatcially >> when I don't know what it's going to be called beforehand? >> >> 4) How do I make my program display/modify those dynamically-created >> fields? Right now, using the attendeeInfo example above, I can create a >> TextInput with an id="firstNameInput" and just say firstNameInput.text = >> "{attendeeInfo.first_name}". That won't work when I have no clue how many >> dynamically-created fields there are, or even what kind of data they're >> going to store... How do I deal with this? >> >> 5) Is there something other than VOs that would fit this situation better? >> Am I limiting myself by using VOs in the first place? Is it just plain >> impossible to do this with VOs? And if so, what are my alternatives? I >> need a structured object that can be passed around with a single reference >> -- I absolutely DO NOT want to pass a bunch of references to a bunch of >> different variables -- that's why I used VOs from the very beginning. >> >> I hope by these questions, you can see how confused I am... And why I'm >> willing to pay someone who's an expert in both Flex 3.5a and ColdFusion 9 >> for their time in helping me understand what I can do here. The entire >> project rests on me being able to do this -- the way it's done currently is >> just not acceptable (having literally hundreds of different versions of the >> program floating around is a very bad way to handle this... There MUST be a >> better way... I'm just not understanding it, and am willing to pay to gain >> that knowledge.) >> >> Thanks a bunch for any suggestions you might give me. And I'm totally >> serious about paying an expert for one-on-one help here... Already talked >> to my boss and got some money cleared for it... So if that's necessary, >> we're prepared for it. >> >> (Oh, I've also posted this on Adobe Forums and FlexCoders Yahoo group... >> So please don't tell me to ask there. It's already been done, with no good >> responses (yet)... <GRIN>) >> >> Thanks, >> Laurence MacNeill >> Mableton, Georgia, USA >> >> >> >> ------------------------------------------------------------- >> To unsubscribe from this list, simply email the list with unsubscribe in >> the subject line >> >> For more info, see http://www.affug.com >> Archive @ http://www.mail-archive.com/discussion%40affug.com/ >> List hosted by http://www.fusionlink.com >> ------------------------------------------------------------- >> >> >> > -- Darin Kohles RIA Developer
