Not to start a debate but It is a bit dishonest to yourself to say that accessibility concerns are only valid for Internet websites and not internal corporate sites.
What happens if the company you work for (appears to be govt by your email address) hires someone with a disability and they need to use your site as a portion of their job? Wouldn't it be better to be proactive and just build the internal site in an accessible (or at least mostly accessibly manner) in the first place instead of having to be reactionary and retro-fitting the site to accommodate this new employee? CSS based design, once you get over the "hump" of learning it isn't really any more difficult than table based design. I can't say it any better than Kay Smoljak does at her blog: http://kay.smoljak.com/archives/?when-is-a-standard-a-standard Her recommended resources are all great too. I'm not trying to push you into adopting a more "standards-based" approach, just trying to provide some additional food for thought. Cheers, Bill On 1/12/06, Tim Van Der Hulst <[EMAIL PROTECTED]> wrote: > 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] > > > -- [EMAIL PROTECTED] http://blog.rawlinson.us If you want Gmail - just ask. ---------------------------------------------------------- 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]
