Awesome form building UI
Check it out: http://wufoo.com/demo/ Can we get this into CCK? Chris
On 18-Apr-06, at 8:40 AM, Chris Messina wrote:
Check it out:
Can we get this into CCK?
It will likely be in the 4.7 version of the forms.module. We're talking about making it a Google SoC project, but it may be too complex for that. So....how come all these damn form builders are subscription-based proprietary bits of nonsense? Chris, what about gathering some funds to make a general purpose form building library, which can then be hooked into various open source systems underneath? -- Boris
"Boris Mann" wrote:
So....how come all these damn form builders are subscription-based proprietary bits of nonsense? Chris, what about gathering some funds to make a general purpose form building library, which can then be hooked into various open source systems underneath?
Again, I would encourage the 'honchos' to review PHP Application Tools (a.k.a. 'pat'). There may very well be some useful bits there, including a robust forms API. (Whether that is Drupal-compatible I'll leave to other evaluators, but I can say that I use Drupal in conjunction with PAT and with pMachine and all has gone swimmingly for about a month and half now.) -- Gary
On the subject of nice DHTML tools, I am quite comfortable with contribs using 3rd-party libraries - as long as everything degrades it's not mission-critical IMO. Putting CCK aside, the form-builder we are discussing is quite straight-forward (if time-consuming) simply because of formapi and AJAX. Where I hesitate is that there are a number of contrib modules surfacing that implement different DHTML libraries. Can I request that the drupal old-school recommend a "preferred" library? This would make way for a module that does nothing more than implement a full javascript library. Cool! I think what jjeff has done so far with S/P Ajax is a great start. Is it possible that this is put forward as the recommended AJAX implementation for other modules to use? I think this would provide a better focal point for cool stuff than what I currently see in the community. sime
Op dinsdag 18 april 2006 19:24, schreef info@urbits.com:
I think what jjeff has done so far with S/P Ajax is a great start. Is it possible that this is put forward as the recommended AJAX implementation for other modules to use? I think this would provide a better focal point for cool stuff than what I currently see in the community.
A / the problem with Drupal community is that Drupal loves to erinvent some wheels, simply because we ca nmake weels that fit better. On top of that, its very undrupalish (but IMO not a good thing either) to implement some toolbox that is only used for a very little part. If you look at core you will see that at least 80% of the functions and features in there are used in core. That is a huge gain since 4.6, which had barely any APIs that were not directly in use. I do not mind choosing prototype or one of the other toolboxes around, but I doubt this will * get into core (see above) * be used much in contribs if its not in core. It would be a first step, though, towards making Drupal more of a CMF! Bèr -- 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
Bèr Kessels wrote:
If you look at core you will see that at least 80% of the functions and features in there are used in core. That is a huge gain since 4.6, which had barely any APIs that were not directly in use.
I just had a closer look at core and I realise I have had the wrong idea all along. So many times people refer to the core javascript as "minimal", but it seems to be more like "just right". Suddenly I find myself of the view that no 3rd party libraries are needed to make a Drupal form builder. And, with a flourish, I switch back into lurk mode... sime
So....how come all these damn form builders are subscription-based proprietary bits of nonsense? Chris, what about gathering some funds to make a general purpose form building library, which can then be hooked into various open source systems underneath?
We could do this fairly handily using a combination of the wForms and Freja libraries, both GPL. They're what drives: http://www.formassembly.com/ Freja does client-side content generation with XSLT. wForms provides various forms-related functionality--repeated form sections, client-side validation, multiple pages, etc. Sample form building interface (this UI isn't GPL): http://www.formassembly.com/form-builder.php The approach would be similar to what is done on formassembly, except that we would use an XML encoding of our $forms arrays: * serialize our $forms arrays as XML * write XSL to render the form XML into wForms format * build forms using wForms, updating XML dataset, which is then unserialized into a $form array. I've included a module for using wForms in Drupal in the Javascript Tools package, http://drupal.org/node/57285. At Goodstorm we're using it to produce a multi-page registration wizard.
"Nedjo Rogers" wrote:
The approach would be similar to what is done on formassembly, except that we would use an XML encoding of our $forms arrays: * serialize our $forms arrays as XML * write XSL to render the form XML into wForms format * build forms using wForms, updating XML dataset, which is then unserialized into a $form array.
I personally refuse any more "XYZ format" (wForms, etc.) of anything. There are __standards based__ forms formats for the web, and those are what __we all__ should be using. The W3C is what we need to honor, collectively, to have any traction on the web and to stop this endless cycle of re-naming everything...twice. Xforms is the W3C next-gen standard, and that is what we all need to struggle toward.
2006-03-14: XForms 1.0 Second Edition Is a W3C Recommendation. The World Wide Web Consortium today released XForms 1.0 Second Edition as a W3C Recommendation. The new generation of Web forms, XForms separate presentation and content, minimize round-trips to the server, offer device independence, and reduce the need for scripting. This second edition adds clarifications and corrects errors as reported in the first edition errata. Second edition publications include the following documents.
* XForms 1.0 Second Edition * XForms for HTML Authors: Part 2 * XForms Quick Reference * XHTML to XForms Converter (XSLT) * Revised XForms Test Suite
<http://www.w3.org/MarkUp/Forms/> -- Gary And Nedjo, while I have your eyes, I've been wondering about this, which involves you... You wrote this about two bug fixes for the Projects module. Note the date.
#7 submitted by nedjo on October 3, 2005 - 15:48 Status: patch (code needs review) » fixed
Both patches applied.
Yet the latest downloadable version [dated this month, 2006] of that Projects module does _not_ have these patches applied. That was a real waste of a whole work day. Is there anything you can do about that?
On 18-Apr-06, at 11:01 AM, Gary (Lists) wrote:
"Nedjo Rogers" wrote:
The approach would be similar to what is done on formassembly, except that we would use an XML encoding of our $forms arrays: * serialize our $forms arrays as XML * write XSL to render the form XML into wForms format * build forms using wForms, updating XML dataset, which is then unserialized into a $form array.
I personally refuse any more "XYZ format" (wForms, etc.) of anything.
There are __standards based__ forms formats for the web, and those are what __we all__ should be using.
<snip /> the rant. wForms is a code library to do client side validation using Javascript. -- Boris
participants (7)
-
Boris Mann -
Bèr Kessels -
Chris Messina -
Gary (Lists) -
info＠urbits.com -
Nedjo Rogers -
sime