How do you find performance? My first app gen dynamically generated forms from scratch. For each field it would take all of the properties for each field (field type, properties, validation rules, etc.) at runtime. It worked fine for a "contact us" form, but when we created an application for matching job seekers to jobs with worthwhile traffic and about 120 fields on the page (I know it's a bad idea, but it's what the client wanted), performance went to heck.
To be fair, though we were generating the forms with a request scope. I guess we should have just cached the display as an application object, but instead we wrote a script that would actually create the CF for the form and save it to a file to be included at runtime (this was in CF 5). We're still trying to determine exactly what we'll generate at design time using regex's and string concatenation versus what we'll create at runtime. Any ideas, experiences or best practices much appreciated! Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Duba, Phillip Sent: Thursday, January 19, 2006 10:29 AM To: [email protected] Subject: RE: [CFCDev] Creating User Controls - cfc or tag? I do this exact same thing when building dynamic modular forms from a data dictionary. The CFC itself is in some persistent scope so the object's already been created and then I have a getFormControl or getViewWidget or another function depending on what the output needs to be as I loop of the dictionary fields. All determination and generation of the HTML is done inside of some CFSAVECONTENT tag and that variable is what is returned. It made the display page that much more compact and I could control the white space better also. Thanks, Phil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Thursday, January 19, 2006 3:28 AM To: [email protected] Subject: RE: [CFCDev] Creating User Controls - cfc or tag? Others may argue against the practice, but i've used CFC's to generate HTML blocks for a long time, and i'm pretty happy with it. Of course, these CFCs are highly cohesive - that's all they do. As a side note, i'm using the cfsavecontent tag and returning the variable generated by the tag and leaving output="false" set on the function. That allows me to tightly control whitespace output, and even run a regex to strip any whitespace as appropriate to the content block on the cfsavecontent variable. The advantage i ran across is that i can cache them in application scope (within a singleton that manages the display of pages) along with all the gateways needed to pull data in from the DB, and that seems to make it quite performant, especially on pages with lots of content blocks. >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Peter Bell >Sent: Thursday, January 19, 2006 6:38 AM >To: [email protected] >Subject: [CFCDev] Creating User Controls - cfc or tag? > > >Hello All, > >My introduction to OOP in CF is a rewrite of a CF5 application >generator in CFMX 7. I have a pretty good domain object model but am >having trouble finding best practices for the UI. > >All of the controller (index.cfm) and model (various cfc's with a >simple façade abstracting the business objects) runs first and then the >model uses rules to determine what screen template to include. For >instance, if form validated, display a list and a "added OK" message, >if it failed, re-display the form screen. It then calls the appropriate >screen. > >The screen is currently looking like being a simple CFML template that >knowledgeable graphic designers can edit and that is comprised of >static HTML, support for variables and basic logic using a generic >syntax (so I can generate in other languages), and a number of widgets. > >The widgets are produced by a code generator that generates (and can >save to files at design time) common UI widgets (table with pagination, >simple form, >n-record update table, etc.) from a set of primitives. The generated UI >widgets can then be passed certain runtime properties (object type to >display, display properties for this instance, etc.) and generate the >appropriate HTML which is then pulled together by the page and screen >templates. > >I'm tempted to describe the widgets something like: <Element >name="PagedTable" Property1="value1" . . . /> for the designers. I can >then use a Regex/parser to turn that into any appropriate >format/include/call. > >How would you recommend calling the user interface widgets? > >I'm tempted to put them into methods of a UI CFC which returns the HTML >string to display. That would also make it fairly easy to refactor to a >Factory pattern to support n-output methods (optimized for different >devices, etc.) but no less than Ben Forta suggests using custom tags >for UI. > >Are there some considerations I'm missing? > >Be gentle on me. This is my first OOP projects and I've been thinking >about this less than a week!!! > >Best Wishes, >Peter > > > > >---------------------------------------------------------- >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] ---------------------------------------------------------- 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]
