Hi Phillip, Glad to hear someone else is wrestling with this stuff as well.
As far as the database abstraction goes. Yeah, my code wasn't perfect but at least it let me get on with other more important stuff (eg UI haha) so the investment in developing it was well worth it. Another wise decision was avoiding learning MachII in favour of Fusebox and then to ModelGlue. Anyhoo, as far as layouting with CSS well that depends. If you're developing internal applications who cares if you use table based layouts? The only argument against tables is accesibility concerns, this is really only an issue for Internet websites. I'll listen to that podcast but i'm quite sure it's just the same old arguments about CSS vs Tables arguments that applies to webpage development. Not sure how applicable that is to Web Application development if thats your game. >> Nowadays tho I use Ajax >Ajax >Model-Glue >FuseBox >Mach-II >Tartan >PLUM >CFCUnit >Coldspring >COAL >Cf on rails Oh yep that was a loaded question. I have yet to try out Tartan, CFCUnit, Coldspring, COAL, CF on Rails although I follow the updates to most of these via the Coldfusion blogs I subscribe to. As far as ajax i've tried out a tonne of these as well, tracking the development in this area also takes a fair bit of time. Various ones for PHP (my favorite is Xajax), a few java ones (ugh), most of the dotnet ones (ajax.net another favorite) and also pretty much every generic one around (see ajaxpatterns.org for comprehensive list of API's) which is where my money is at. Dojo and Tibet are heavy duty DHTML/Ajax toolkits but in early dev (ie almost totally unuseable haha). Waiting on Plex too which looks promising. I have a wrapper for coldfusion which I can use to work with generic ajax API's. Currently using script.aculo.us for some UI effects, XHCon/JSON for Ajax, and well a bunch of js for various widgets (which I hope to replace when I find a decent DHTML toolkit that has a good set of widgets). > I still consider myself to be in the phase of simply learning the syntax, much less deciding which Framework (Design Pattern) to use. Well frameworks help with MVC and Data Access patterns but yeah. Learning curve with these.. > And I'm afraid that as I learn the syntax, I develop my own framework, one that would seem crude compared to these more fully developed ones. Well yeah avoid building an entire framework if you can. hehehe Good luck, TiM -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Phillip Senn Sent: Friday, January 13, 2006 10:12 AM To: [email protected] Subject: RE: [CFCDev] State of Coldfusion UI Development TiM, Wow! Your post is so timely for what I'm doing. I've spent the last X amount of time developing a CRUD environment so that A) It's secure B) Every SELECT, UPDATE, INSERT, DELETE is logged C) It's easy for the web developers to use (I give them VIEWS that are already joined) D) It's easy for the web developers to use (I give them custom tags that only require a tablename and hidden ID field to retrieve, update and delete) Just TODAY, I've been wrestling with reworking table based layout to CSS because the last podcast from HelmsandPeters.com talked about Head First HTML. Listen at 9 minutes into the program. Without the benefit of actually reading the book, but inferring from what they were talking about, I think they're advocating CSS positioning. > it's become something of an obsession for me over the last year Rightly so since you know that the decisions that you make are going to be duplicated throughout all future projects. > Nowadays tho I use Ajax Ajax Model-Glue FuseBox Mach-II Tartan PLUM CFCUnit Coldspring COAL Cf on rails I'm in shock. I still consider myself to be in the phase of simply learning the syntax, much less deciding which Framework (Design Pattern) to use. And I'm afraid that as I learn the syntax, I develop my own framework, one that would seem crude compared to these more fully developed ones. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Van Der Hulst Sent: Thursday, January 12, 2006 2:17 PM To: [email protected] Subject: [CFCDev] State of Coldfusion UI Development Whilst I'm at it I might as well reiterate my other major gripe with Coldfusion development. I've stated these opinions before (see below) and I do realise this is a mailing list for CFC development but yeah; I'm still wrestling with this one after some 18 months although things have gotten A LOT better since then. Building Web Apps UI's with Coldfusion & HTML/CSS is painfully slow. [The issue of HTML's suitability for Web App dev has been thoroughly beaten to death over the last year so I feel somewhat vindicated in my earlier position on this] I still spend an estimated 30% of my time building the interface. Granted it's become something of an obsession for me over the last year and my productivity has shot up so I don't feel like I'm wasting as much time on trivial form creation as before but still. Example, trying to RAD layouts with CSS is a joke; I probably spent nearly a couple of weeks in total building various layout managers but with limited success. CFMX7 supports basic horizontal/vertical tags which translate into tables hehe but it's still a far cry from a proper layout manager ala Java Swing GridBoxManager, Flex, etc which can handle resizable layouts really well and be built very quickly. I eventually got over the fact that Coldfusion didn't have a GUI builder like Visual Studio and consoled myself with the fact that I could achieve pretty sophisticated UI's by hand coding HTML. I did have moderate success with a custom UI tag library tho. Another UI issue I tried to solve was databinding as I got sick of having to code trivial update CRUD. I ran into issues when I tried to build a solution to this. Doh, several days down the tube that time. Mostly I used my table DAO for saving (eg update(form) -Primary key is hidden field so it knows what record to update). Nowadays tho I use Ajax to save each field via onChange events. Makes things a damn site easier. Biggest issue I have these days is wrestling with separation between server (CFM/CFC) and client (HTML/Javascript) code. Currently I have a CFC for pushing back updates on the client (ie pumps out Javascript commands to update Divs after a callback) and also regular javascript callbacks but I fear I should be separating the two so that the model resides on the server and the view entirely client driven. Anyway, haven't really got my head around that one yet. I think this direction is being pursued by some of the DHTML toolkits in development these days. Backbase (http://www.backbase.com/) is a good example tho it utilizes an intermediatory server and costs a bundle. You can build very slick Interfaces (ie think Flex but HTML). Layout tags and a wide range of widgets for example. Anyway... Dojo toolkit and others show some early promise :) I guess that's sorta answering my question somewhat. Relegate the server to generating data (eg Model+Controller=>XML) and have the client render everything (view). At least that way you're not getting tied to any particular server language and don't have to fight that language to build UI's. Hmm, oh well better shut up now. Will report back in another 6-12 months. ------------------------------ My Previous posts on the subject: ------------------------------ CSS layout manager for webapp dev? (July 2004) http://www.mail-archive.com/[email protected]/msg05679.html UI custom tag library (Nov 2004) http://www.mail-archive.com/[email protected]/msg07105.html OT: superplatform vision (Jan 2005) http://www.mail-archive.com/[email protected]/msg08022.html Thanks for listening, TiM ---------------------------------------------------------- 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]
