On 20-Feb-06, at 2:22 PM, Ber Kessels wrote:
And here I do not agree with the "does not degrade" argument either: this is not something the view side or even an everyday admin task. This is a very rare task (once per site), and for that, grab a JS browser, this is 2006, even a PDA runs JS.
oh? And what about people with old PCs? what about blind people? What about people who have no say over the PCs and the software it runs.
If it would run, but less nice, without JS, there is no problem. But this *does nothing* without JS, it does not even render normal HTML/forms. without Js it is useless. That is a very bad thing IMO.
Every browser out there has flash. even PDAs do: lets build a flash form builder. Or no, a JAVA. Hell no, we can make a XUL and activeX one, virtually every system has access to one of the two.
*blush* well look at the flurry of interest in my poor little neglected old forms.module. First off, lemme say I think there are two things at work here: 1) A common form-building library - for "user created" forms ... This was the original intention of forms.module was to be a wrapper around the (then weak) "form api" - so that various modules - profile, survey, (at the time) event, flexinode, etc could have a common, consistent way to provide a UI & serialization techniques and use common code. My initial hope, even, was that forms.module would make it to core. (My thought at the time was forms.module : form api :: menus.module : menu system). I think this is still the "right way" (tm) ... and now with a proper form api in core, the time has come to revisit this (imnsho) . 2) fancy JS/AJAXy drag 'n' drop yummy goodness for this UI. I actually agree with Ber (OMFG! ;) that the lack of degradability for the jotform stuff makes it not a good candidate to be the /only/ way to handle form building. However, it is clearly a quite attractive & easy way to get the job done. Options, people, options. The JotForm approach has the nice benefit of being self-contained (i.e. single page) which has always been a cross to bear with forms.module based on the number of clicks / reloads /etc required to build a simple form. it's significantly tedious. I've already done some thinking on new things to do with forms.module in 4.7 ... 1) is still largely the goal... and 2) definitely looks like an interesting approach. Of course, patches accepted and welcome as always :) -- James Walker :: http://walkah.net/