First, let me say that I have been roundly criticized for taking the approach of NOT using VOs.
Second, I use .NET & FluorineFX. Having said that, I created my applications in such a way that my middle tier has a few generic methods for querying, updating, inserting data from a DB (usually Oracle). There is also a generic middle tier routine to handle stored procedures as well. My presentation layer, Flex, builds a SQL statement, and passes it to the generic middle tier that processes it (generally just passes it to the DB), and returns to Flex either an array collection (fully typed), if it was a query, or the results of the non query sql statements. If one were clever, using the approach above, one could create a Flex app that requests a table structure from the DB, and builds a data entry screen on the fly. You may want a "schema" table that contains data validation type info that would be read in conjunction with the table structure to allow edits to be performed by flex. When complete, all you would need to do is modify the DB to create the table structure the customer needs, and add records to the schema table, and you have a new data entry module. By the way, my main reason for resisting the VO structure, is I thought that keeping multiple copies of the VO in sync would be a PITA. Anytime you modified a table you need to modify at least two VOs, and potentially recompile middle tier and presentation layer programs. Paul --- In flexcoders@yahoogroups.com, Jake Churchill <reyna...@...> wrote: > > You could probably try having a base VO for all the properties that you know > will be there and include a single property in the VO which would be either > a Dictionary or a generic object used as an associative array to handle all > your custom properties. Then just populate the VO like you normally would > and when it comes to extra properties, throw them in that one extra VO > property. You'd have to have some kind of parsing method on both ends but > I'd think this would work without too much trouble. > > -Jake > > On Tue, Mar 2, 2010 at 3:21 PM, Laurence <lmacne...@...> wrote: > > > > > > > We're using an SQL database with a ColdFusion "intermediary" between the > > Flex app and the database... I've used XML files to configure a couple of > > the components -- give the user the option to change the layout of a > > component, for example, by modifying the contents of a config.xml file, that > > sort of thing... But I don't see us replacing our database with a bunch of > > XML files... (Or maybe I completely misunderstood your reply, which is quite > > possible...) > > > > I was hoping that there might be a way to get the program to modify its VOs > > by reading from an XML file what fields I want the VO to store... But > > honestly, I don't care where that info is stored... I just need to figure > > out how to dynamically modify a VO (and have ColdFusion realize that the VO > > has been changed by the Flex app) so I can deal with databases that have had > > fields added or changed without having to re-compile the entire program > > every time... And then, of course, how to reference these > > dynamically-modified VOs in my program. > > > > Thanks, > > L. > > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, Nick > > Middleweek <nick@> wrote: > > > > > > Hi Laurence, > > > > > > I'm pretty new to Flex so there might be reasons to stick with Value > > Objects > > > that I'm unaware of but you can definitely read and write XML and > > generate > > > forms, layouts, etc on the fly based on the XML contents. I've used E4X > > to > > > query XML data that I've sucked in from an HTTP call, modified the XML > > using > > > E4X and pinged it back up to the HTTP server to save the XML data for > > later > > > use. > > > > > > Hope that helps... > > > > > > > > > Cheers, > > > Nick > > > -- > > > http://blog.middleweek.co.uk/ > > > > > > > > > > > > On 2 March 2010 19:19, Laurence <LMacNeill@> wrote: > > > > > > > > > > > > > > > The program that I'm working on is for a company that does > > registrations > > > > for conventions and trade-shows. Different clients want different > > > > information stored for each show. Most of the information is the same > > from > > > > show-to-show, but every show has certain customizations that need to be > > > > done. > > > > > > > > The way they're doing it now is by going into the source code of their > > > > program and modifying it that way. We could do the same thing with our > > Flex > > > > app, but I'm trying like heck to avoid that... > > > > > > > > The problem I'm running into is the Flex Value Objects -- they pretty > > much > > > > have to be compiled into the .SWF file, which means we're stuck > > modifying > > > > source-code and re-compiling for each individual show. Not the solution > > we > > > > want. > > > > > > > > Is there a way to dynamically create and/or modify Value Objects so > > they > > > > can be changed without re-compiling the .SWF file? So that if a > > particular > > > > client wants stuff tracked that a different client doesn't want > > tracked, we > > > > don't have to create a generic version of our database that has all > > these > > > > extra fields in it, which most clients don't need? > > > > > > > > As it stands right now, the Value Objects force us to make every > > database > > > > for every show exactly the same -- unless we modify the Value Objects > > for > > > > each individual show and re-compile a separate .SWF file for that > > show... If > > > > there were a way to write, say, an .XML file that the program could > > read and > > > > modify itself accordingly for each show, that would be brilliant. Is > > there a > > > > way to do that? > > > > > > > > Thanks, > > > > Laurence MacNeill > > > > Mableton, Georgia, USA > > > > > > > > > > > > > > > > > >
