*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.* I wouldnt recommend doing that ever from the presentation layer.. unless your middle tier has no chance of being exposed over the web and there is no smart and crazy user of your app who wants revenge :-) . There are tons of things achievable through SQL queries which we cant even imagine( it could format the hard drive). the kind of sql sanitization required over each such call would be too much. On Wed, Mar 3, 2010 at 9:54 AM, aceoohay <pa...@compuace.com> wrote: > > > 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 <flexcoders%40yahoogroups.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><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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
