forgive me for butting in but I just want to add a quick 2c 1) metadata "percolating" up to the client/view: we had metadata in some areas that changed per request (to drive the UI/javascript/page logic). the only way to do it (integrated with the data) was to use XML (with javascript...survivable). BTW, this XML was generated deep in the app using the method below with struct key lookups, etc
2) metadata for simplifying back end coding: it depends on how you' like to hang onto the metadata. We also had large representations of the database (abstracted enough to be useful) held in (Server**) memory. this covered pretty much all you mentioned plus lots more but as structure keys, not XML (much like how config values are done within .NET). Last I saw of the project it was doing this on server start but there might be a better way... the trick is what happens with changes in the metadata to the sourounding code. the boss had a habbit of adding a column or lengthening a field every other week as he changed his mind about something...with 777+ tables it was something to keep in mind when the meta data changes (i.e. you could probably cope with a text field getting longer but how about an INT to a STRING? or an INT to a GUID?) just mt 2c worth. I'd be curious to see what you decide and how cheers barry.b **but application scope would work just as well On 31/01/06, Peter Bell <[EMAIL PROTECTED]> wrote: > I have a neta data driven application generator which I am currently porting > from CF5 to CFMX7, so I'm considering similar issues. I think you need to > consider two things: performance and DRY (don't repeat yourself). > > Is the meta data going to be anywhere else? You only want to store and given > piece of meta data in one place otherwise you have to remember to update the > copies. > > In terms of performance, what will be the performance hit generating the > form fields using the form meta data at runtime? If you need better > performance you may need to pre-generate things like the form fields to save > all of the field concatenation of HTML (side hint - for concatenation, use > arrays and then array to string - supposed to perform much faster). > Alternatively, use lazy instantiation and application scopes so if you have > to do the extra work only do it once per application rather than per session > or per page request. > > You could use an XML file, but with the file operation and the > deserialization of the XML, I'd make sure you application scope it (so if > there is a huge amount of data this may not work out well, but for most > applications it wouldn't be a problem). > > Best Wishes, > Peter > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Michael T. Tangorre > Sent: Monday, January 30, 2006 8:13 AM > To: [email protected] > Subject: [CFCDev] Bean / Meta Data > > > In my Bean CFCs I have the standard methods: getSomeProperty(), > setSomeProperty(), getInstance(), setInstance(), and validate(). What I am > toying with is "how much" data/meta data should/could I store about the > properties within the bean and how much (if any) might be better suited for > "properties file" such as an XML file. What would be nice is to have some > meta data about the properties themselves for different purposes: > > form element attributes: maxlength,id,name,label > cfqueryparam attributes: maxlength,null (evaluate expression), cfsqltype > javascript validation server side validation (within the Bean's validate > method) > > My question is... how much of this "meta data" would/could/should be stored > in the Bean itself and how much would be better suited for a properties file > of some sorts... and is all this even worth it? Say for instance, a required > field changes or a field's maxlength increases from 500 characters to 1000, > it would be nice to denote that in one area and have that piece of meta data > accessible anywhere the property is used. > > Is all this overkill? I haven't implemented anything yet but I can > definitely see some benefit of doing so. > > Your thoughts? > > Tango. > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
