Hi Cody, Many thanks for the pointer. Will check it out!
Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cody Caughlan Sent: Thursday, January 19, 2006 2:03 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Creating User Controls - cfc or tag? In regards to "wizards" (workflows), FarCry has a solution like this, called PLP (page level process? or something like that). FarCry code is pretty hefty to look at, but you might want to download it and try to replicate it. Its broken out into separate files and seems to be pretty modular so it could be promising. It supports jumping around between steps. Not sure "incomplete" transactions are handled. FarCry: http://farcry.daemon.com.au/ /Cody -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell Sent: Thursday, January 19, 2006 10:52 AM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Creating User Controls - cfc or tag? Thanks for the hint on building strings using an array and an array to list. I had read that the java list operations were expensive so that's a great tip! Personally I allow for XML import but keep my primary meta-data repository in SQL server as I think it gives more flexibility and performance, but then I can afford to tell my clients that they need to use a database (and what type) as I host almost all of them. I know I get the network overhead of the call to the DB server, but I feel that for large data sets it is more efficient and for small data sets (where it may well be quicker to have a file read and to deserialize the data) the amount of time required is so small that I don't care. Also, wherever I think performance will be an issue, updates will be rare and reads will be frequent, I tend to write a script to generate hard coded CFML. For instance, I used to generate stub pages named things like "about_us/history.html that both allowed users to access "pretty" URL's and which saved a database query by just CF setting all of the properties for the selected page object. My edit page script called a generic publisher using object based rules to auto generate the stub page or other persistent file so maintenance wasn't an issue. Of course, now I'm getting into URL rewriting and instantiating page objects instead (although for most sites I'm looking to instantiate application scoped page objects as most of them have well under 200 pages with only 20-30 small properties, so the memory required to store them is minimal and it saves a round trip to the database for each request). Talking of multi step wizards. Do you have any good ideas on creating a generic control of flow language that is specific to wizards, and how do you handle users going in a non standard order through the pages and/or incomplete wizard "transactions"? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Duba, Phillip Sent: Thursday, January 19, 2006 12:34 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Creating User Controls - cfc or tag? Performance all depends on the amount of data you're getting to feed the form-based control generation and what other logic is in there for looping. Right now, I take a pretty heft XML document and generate the form in about 1 second. This includes building queries for the information that might have been entered, setting parameterized default values for non-form based values (it's a multi-step wizard application), building JavaScript required for the form, and finally the form itself. It takes another second if the xml isn't loaded already into memory. The one thing I did use is the ArrayAppend()/ArrayToList() technique for building long strings for the JavaScript since I have to loop over every form field to determine the JavaScript validation for the form or entered data. That saved a lot of time in building those strings. Thanks, Phil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell Sent: Thursday, January 19, 2006 12:07 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Creating User Controls - cfc or tag? 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: CFCDev@cfczone.org 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: CFCDev@cfczone.org 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: CFCDev@cfczone.org >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 >cfcdev@cfczone.org 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/cfcdev@cfczone.org > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
