[development] Forms.module for 4.7
James Walker
walkah at walkah.net
Mon Feb 20 20:36:29 UTC 2006
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/
More information about the development
mailing list