See this? http://www.jotform.com/index My personal idea (i.e. handwaving) for forms.module for 4.7 is that it would provide support functions to be able to build forms on the fly. Both Survey.module and perhaps CCK (e.g. for custom built node/ add forms) would use forms.module for this functionality. Thoughts on this? Anyone feel like pooling resources/funds to get this built? -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
Boris Mann wrote:
See this? http://www.jotform.com/index
My personal idea (i.e. handwaving) for forms.module for 4.7 is that it would provide support functions to be able to build forms on the fly. Both Survey.module and perhaps CCK (e.g. for custom built node/ add forms) would use forms.module for this functionality.
Thoughts on this? Anyone feel like pooling resources/funds to get this built?
Here is my first pass at a high-level list of requirements. 1) Use drag & drop to place items on the form. Duh, but it's a top level requirement. 2) Use formsapi properties -- we have a relatively complete list of the items and properties that are available by default. These could be implemented verbatim. 3) Use AJAX to send to send modified form items to Drupal for rendering. 4) When finished, send completed $form array either to Drupal or printed cleanly for the user. Thus the tool could be used by module developers to easily design their own forms, OR the tool could be used by live Drupal sites to create user modified forms. In this case, an additional requirement of permissions on some formsapi attributes may be required, or at least a very good security run must be done. 5) Some macros to fill select boxes/checkboxes would be a nice addition. i.e, roles, users, nodes that match <x>, etc. This could easily be insecure in the user-built forms but would be very helpful for developers. I'm all excited about this. Pity I haven't any free time to do this!
Op zondag 19 februari 2006 14:41, schreef Boris Mann:
fly. Both Survey.module and perhaps CCK (e.g. for custom built node/ add forms) would use forms.module for this functionality.
Thoughts on this? Anyone feel like pooling resources/funds to get this built?
I do not like this. It does not degrade. Try it with JS switched of. And I dislike the idea of making CCK depending on this. It would build a line of dependencies: Foo depends on CCK depends on Forms depends on Core. I it means, in practice that any module that requires CCK is rather hard to install because it requires already two other modules to be installed. Bèr
it means, in practice that any module that requires CCK is rather hard to install because it requires already two other modules to be installed.
Sorry, but this is bullshit. Installing N modules is not significantly harder than installing one -- if you can install one, then you know mysql tada, tada. Oh and we do not necessarily need mysql now, we have a coolio update system and even hook_install. 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. I will help however I can this cooooooool form builder thing. If you need form API help, you know where to find me.
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.
On 2/20/06, Ber Kessels <ber@webschuur.com> 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.
Ber You are right in most of your arguments (graceful degradation, ...etc) But, remember: this is an admin interface, not a user interface. So, the end users are not affected by that at all. If this is made as a form designer, and is optional, with a non JS way to do it, then I am all for it. Heck, Admins will find a way to turn on JS on their browser or download one who has.
If this is made as a form designer, and is optional, with a non JS way to do it, then I am all for it. Heck, Admins will find a way to turn on JS on their browser or download one who has.
I am against any difference in user/admin requirements. I said it as a joke, but if we make this difference, then we can just as easy say: use FF, and we do it all in XUL. XUL s absolutely fabulous for this. I do not like the idea of having to put in our "required software" FF>1.0 IE>6 etc. That we limit ourselves in PHP and SQL versions, allright,. And is is that hard to make something that *works* without JS? Its not. Just this lib cannot do it.
On 21-Feb-06, at 2:09 AM, Ber Kessels wrote:
If this is made as a form designer, and is optional, with a non JS way to do it, then I am all for it. Heck, Admins will find a way to turn on JS on their browser or download one who has.
I am against any difference in user/admin requirements.
It's not in core. You're welcome to not use the module.
I said it as a joke, but if we make this difference, then we can just as easy say: use FF, and we do it all in XUL. XUL s absolutely fabulous for this.
Yep, would love to see a XUL version. Please commit to your sandbox.
I do not like the idea of having to put in our "required software" FF>1.0 IE>6 etc. That we limit ourselves in PHP and SQL versions, allright,.
And is is that hard to make something that *works* without JS? Its not. Just this lib cannot do it.
The pointer was an example of what can be done -- the lib isn't open, we could build this with Forms API. No more Ber baiting this thread.... -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
Ber Kessels wrote:
If this is made as a form designer, and is optional, with a non JS way to do it, then I am all for it. Heck, Admins will find a way to turn on JS on their browser or download one who has.
I am against any difference in user/admin requirements.
I said it as a joke, but if we make this difference, then we can just as easy say: use FF, and we do it all in XUL. XUL s absolutely fabulous for this.
I'd rather have an XUL one than a JS one. :p
I do not like the idea of having to put in our "required software" FF>1.0 IE>6 etc. That we limit ourselves in PHP and SQL versions, allright,.
Did I mention I want to drop mysql 3 support?
And is is that hard to make something that *works* without JS? Its not. Just this lib cannot do it.
I've actually no idea if one can. This lib is not Open Source and therefor not usable by us anyway. I would not mind to have a form builder in JS, as long as it degrades gracefully. Even if it didn't I'd be ok with it as long as it is a contributed thing. Actually, I would even like to have a form builder that isn't part of Drupal at all. You only build forms very rarely, I'd prefer to build it outside of Drupal and then upload the result. No need to parse a form builder for each page request. Cheers, Gerhard
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/
oh? And what about people with old PCs? what about blind people? What [six lines deleted] Every browser out there has flash. even PDAs do: lets build a flash form builder.
You managed to contradict yourself in a short letter: flash for blind people? Ber, you are tiring me, seriously.
Op maandag 20 februari 2006 22:11, schreef Karoly Negyesi:
You managed to contradict yourself in a short letter: flash for blind people? Ber, you are tiring me, seriously.
I will add an </cynical tone> next time .... Off course I do not like a flash-only interface! geez. But it is just as silly as a JS only interface! -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
This new library (JotForm) looks amazing.. the demo on the website has me drooling all over my desk. BUT there's a big issue that concerns me... Licensing: what license is JotFrom released under? I couldn't find any reference to the license or terms of use anywhere on the site. All it says (in the FAQ) is that "During the beta period, it is completely free". Even that doesn't sound too promising: clearly, the author plans to charge for (at the very least) commercial use of the library. If so, JotForm will be neither a GPLed or a GPL-compatible application, and therefore we will not be able to use it in Drupal. Also, Ber, I too think you're overreacting. Nobody wants to jave a completely JS interface as the ONLY interface to anything in Drupal. If we ever did implement something like JotForm, it would only be as an alternative interface to, say, the underlying CCK API. Jaza. On 2/20/06, Bèr Kessels <ber@webschuur.com> wrote:
I do not like this. It does not degrade. Try it with JS switched of.
And I dislike the idea of making CCK depending on this. It would build a line of dependencies: Foo depends on CCK depends on Forms depends on Core. I it means, in practice that any module that requires CCK is rather hard to install because it requires already two other modules to be installed.
Bèr
Jeremy Epstein wrote:
This new library (JotForm) looks amazing.. the demo on the website has me drooling all over my desk. BUT there's a big issue that concerns me...
Licensing: what license is JotFrom released under? I couldn't find any reference to the license or terms of use anywhere on the site. All it says (in the FAQ) is that "During the beta period, it is completely free". Even that doesn't sound too promising: clearly, the author plans to charge for (at the very least) commercial use of the library. If so, JotForm will be neither a GPLed or a GPL-compatible application, and therefore we will not be able to use it in Drupal.
Also, Ber, I too think you're overreacting. Nobody wants to jave a completely JS interface as the ONLY interface to anything in Drupal. If we ever did implement something like JotForm, it would only be as an alternative interface to, say, the underlying CCK API.
Jaza.
You know, I quickly assumed JotForm was basically just a demo. It's clear that the author of JotForm hopes to get something out of it. The thing is, I think any number of talented developers around Drupal could put together something that, perhaps not quite as slick and polished as that, would do very well for Drupal. The core of JotForm is likely to be the HTML generation properties...and a Drupal-specific tool wouldn't even need that. It'd just need to know what gizmos and widgets Drupal has available and what attributes they support. Drupal would do the rendering, and the front end would simply do the arranging.
On 20-Feb-06, at 2:53 PM, Earl Miles wrote:
Jeremy Epstein wrote:
This new library (JotForm) looks amazing.. the demo on the website has me drooling all over my desk. BUT there's a big issue that concerns me... Licensing: what license is JotFrom released under? I couldn't find any reference to the license or terms of use anywhere on the site. All it says (in the FAQ) is that "During the beta period, it is completely free". Even that doesn't sound too promising: clearly, the author plans to charge for (at the very least) commercial use of the library. If so, JotForm will be neither a GPLed or a GPL-compatible application, and therefore we will not be able to use it in Drupal. Also, Ber, I too think you're overreacting. Nobody wants to jave a completely JS interface as the ONLY interface to anything in Drupal. If we ever did implement something like JotForm, it would only be as an alternative interface to, say, the underlying CCK API. Jaza.
You know, I quickly assumed JotForm was basically just a demo. It's clear that the author of JotForm hopes to get something out of it. The thing is, I think any number of talented developers around Drupal could put together something that, perhaps not quite as slick and polished as that, would do very well for Drupal. The core of JotForm is likely to be the HTML generation properties...and a Drupal-specific tool wouldn't even need that. It'd just need to know what gizmos and widgets Drupal has available and what attributes they support. Drupal would do the rendering, and the front end would simply do the arranging.
@Jaza: re license, JF is an example of what can be accomplished. I left a comment with the guy asking what he wants to do with it, but like Earl says, we can probably build most of this directly with the Form API. @Ber: you can build all your forms manually, and make a Drupal4Blind....for 99% of people, they will find an admin with a JS browser to build a form in 10sec. Hallo from Italy.... -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
On 21 Feb 2006, at 11:36 AM, Boris Mann wrote:
@Ber: you can build all your forms manually, and make a Drupal4Blind....for 99% of people, they will find an admin with a JS browser to build a form in 10sec.
Agreed. I think a form builder, and quite possibly constructing cck node types and views are tasks that are far better suited to javascript implementations than tedious multi step forms and wizards. I also don't believe that these admin tools should be provided with core, but core should be able to understand the structures created by them. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
@Ber: you can build all your forms manually, and make a Drupal4Blind....for 99% of people, they will find an admin with a JS browser to build a form in 10sec.
Spoken straight from my heart.
Hallo from Italy....
Hey man, if you came this close, what about visiting Budapest? :)
Op dinsdag 21 februari 2006 11:18, schreef Karoly Negyesi:
@Ber: you can build all your forms manually, and make a Drupal4Blind....for 99% of people, they will find an admin with a JS browser to build a form in 10sec.
Yea cool. Drupal4PDA, Drupal4Opera, Drupal4OldBrowsers, Drupal4Lynx, Drupal4smallservers, you get it. Standards are there to abide. If we choose to break them, fine. But only if there is a good reason to, and *never* *ever* because we are too lazy to figure out how to write well-degrading stuff. ever! And even if this is a supplement, a contrib, a layer of icing. How hard is it to develop it right? To develop it standards compliant and degrading? If the answer is "too hard", then we are either too lazy, or not yet up to the task of developing JS interfaces.
Spoken straight from my heart.
Suddenly I am getting *really* concerned. Already four core contributors have literaly said that they no longer care about JS degrading.... I hope that this will not infect the way Drupal evolves. Hey, folks, c'mon, I am not anti JS, not at all! I am just very much anti BadJS. And since 99.5% of thje JS out there is just plain Bad (including a fast growing part of the current AJAX farts), from its core, that may sound the same. A *good*, degrading, form builder, using whatever technology: +100. A *bad*, non degrading, form builder: -10000 Bèr [1] alert("sorry! your browser is not supported, please download the latest internet explorer here") [2] document.write("Your browser does not support javascript, please download the latest netscape") http://www.google.com/search?hl=en&lr=&q=%22Your+browser+does+not+support+ja... :) [3] I mean, I can use Gmail fine, from any browser, including lynx (only tried once, never really used it). I cannot use digg on anything w/o JS, simply because these folks were too lazy to add normal GET processing to the digg-this links. How hard is it to add digg.com/Web_2.0_XHTML_CSS_Page_Generator/digg_it links, and to add a simple onClick() to hijack working JS? Bah! -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
On Wed, 2006-02-22 at 10:07 +0100, Bèr Kessels wrote:
And even if this is a supplement, a contrib, a layer of icing. How hard is it to develop it right? To develop it standards compliant and degrading? If the answer is "too hard", then we are either too lazy, or not yet up to the task of developing JS interfaces.
As much as I agree with people that we need to friendlify the CCK/Views/Workflow interfaces to make them grep-able (and to fit on the screen) I think I agree with you here. The first step is to build a plain but functional XHTML/CSS interface and then add javascript on top. Sure we should wireframe the ideal interface first, but if we aim for javascript first, rather then the XHTML/CSS 'middle stage' then I think that will lead to poor accessibility. Among the obvious problems with locking users out of the site it could mean that organizations with US federal government funding could not use Drupal! Just my 2c. - Owen
Have any decisions been made on this? We're interested in seeing this happen. Anyone already working on it? Would a reverse-bounty work well here? Ian
A *good*, degrading, form builder, using whatever technology: +100.
-- Ian Ward Technology Development and Discovery Development Seed http://www.developmentseed.org http://www.developmentseed.org/blog Tel. 1-202-250-3633 Fax. 1-806-214-6218 Skype: developmentseedperu
participants (12)
-
Adrian Rossouw -
Ber Kessels -
Boris Mann -
Bèr Kessels
-
Earl Miles -
Gerhard Killesreiter -
Ian Ward -
James Walker -
Jeremy Epstein -
Karoly Negyesi -
Khalid B -
Owen Barton