History module

[apeisa]

There is history module on the roadmap for PW 2.3. (May 2012)

Built-in capability for building forms in the admin (for front end use) and processing and saving form results.

Addition of a Page History module, enabling one ot track revisions/versions of page edits.

How do you feel about schedule on this one Ryan? There are two big features planned for 2.3 (this and form editor), so I don't think that May is realistic - or is it?

[ryan]

The form builder probably won't be part of it, but the history module will (and already a good start with that). For the form builder, I've either got to wait till I get a bunch of time off work to do it, a client wants it and is willing to subsidize it, or we get a sponsor for it. So it's something I definitely see us getting eventually, but probably shouldn't nail it down to a version. I'm also really interested to see where Netcarver's form builder is going and see if there's collaboration potential there.

I've wanted to wait to officially announce 2.2 till language and repeater functions were bulletproof. But I've been fixing minor issues in both as recently as this week, so feel like I need to have at least a week of no issues coming up before we'd consider 2.2 ready for announcement. I still also need to resolve the repeater / page clone issue. 2.3 will likely follow 2.2's announcement by 2 months, so likely sometime this summer.

[teppo]

It's obvious that stuff like this takes time -- and building multiple features, especially when they're big ones, at same time is nowhere close to a good idea -- but I just had to drop in to say that we're really, really looking forward to the form builder too.

Anyway, it's always good to get a heads up about how things are going, so thanks for sharing this Ryan! I'll go check what Netcarver's been building now

[netcarver]

Hi Teppo,

I've some code in a private git repo that some folks here have access to (Antti is using it at present). It's a very young bit of code, based on an idea I had for a DSL for building webforms. Currently it is not tied into ProcessWire but does have a dependency on Will Bond's flourish library.

To get a brief overview of what the DSL looks like please check out this gist. There are also a few (early) snapshots of it in action on flickr.

I'm at the limit of invitations to that repository but if there is general interest I could be persuaded to move it onto github once I've got a couple of important items crossed off its to-do list. Whilst I'd love to see a graphical form builder based on this, it's a long way off yet. What you can easily do with it right now, is specify forms with it within your templates.

[teppo]

Thanks netcarver - had a quick look at those and it does look promising already! Please, keep up the good work -- and make this available for us "outsiders" as soon as you feel it's mature enough for that

Somewhat offtopic: what you're building there kinda reminds me of Zend_Form and actually made me think about putting up a quick proof-of-concept of using that in a PW site. If not for production use, might at least be interesting to see how (and if) it works out.

[netcarver]

... but the history module will (and already a good start with that).

This will be a fantastic feature to have.

[apeisa]

Ryan: I think that sounds like a good way to go. Actually 2.2. is pretty huge:

• Multilang support
  
• Repeater (a la matrix)
  
• Field context settings
  
• Field widths
  
• Page cloning
  
• Page publish -permission
  
• Datefield improvements
  
• Did I forgot something?
  

So having little bit faster and thinner 2.3 just makes sense. If form builder is dropped, then there are only 3 items on the roadmap:

• Addition of a Page History module, enabling one ot track revisions/versions of page edits.
  
• Field duplicate feature in the Admin > Setup > Fields.
  
• JS session monitoring to handle multiple users editing the same page.
  

About form builder: I gotta say that I love what Steve has done with his form classes. What I think could be possible roadmap is to build js form builder that outputs the required code for Steve's class. Then PW would just have a module which allows creating those forms (using that js form builder), saves entries and allows admins to browse those entries.

[teppo]

Antti: regarding the form builder, you might also want to check out how this stuff is handled in Form Builder Plugin for Pimcore: http://www.pimcore.org/wiki/display/PLUGINS/Form+builder+plugin. Pimcore uses Ext JS heavily for all it's views but putting that aside the basic UI concept there doesn't seem too far from what would be required here.

[ryan]

Ryan: I think that sounds like a good way to go. Actually 2.2. is pretty huge:

You are right, quite a lot in it. It could have just as easily been a couple of versions, and maybe should have been. But I'm mostly focused on just getting stuff in there that's needed, when needed, and version numbers are secondary. But I'm feeling pretty good about where the multi language support is in stability, and once the repeater/clone issue is resolved, should be able to make 2.2 more official.

Field duplicate feature in the Admin > Setup > Fields.

We already have this (Edit Field > Advanced > Duplicate/Clone).

When it comes to a form builder, I think long term we'll do great things here. Short term (v2.3), maybe we should have a relatively simple built-in contact form module, just so solve the simple/common needs.

[ryan]

You guys got me thinking about this form builder and now I can't get my mind off it. I've taken a look at Netcarver's and Zend's form classes, and both look awesome. I'm particularly impressed by Netcarver's system and hope to be putting it to use sometime soon.

Focusing on this a lot the last few days also made me realize that a PW formbuilder and the existing Inputfields have a lot of common ground. Enough so that it probably doesn't make sense for a PW formbuilder to venture outside of that. But it does make sense to upgrade PW's Inputfield system to make it more flexible consistent with the needs of a formbuilder. It's easier to maintain and support if there is one system rather than two. It wouldn't replace a system like Netcarver's or Zend's, but would provide a good middle ground for the less complex form needs.

As a first step, I figured I'd see how well Inputfields would adapt for the sort of portability a formbuilder would need. The goal was to be able to take an array or JSON string, and have it render as a form using PW Inputfields, as they are now. This is something I'd not tried before, but the first step we'd need in order to easily store a form schema for a form builder.

A small 20-line recursive function takes that array and dynamically creates a form composed entirely of PW Inputfields. All that's left to do is call $form->render(); I built a small test form and had success with it. Yesterday a friend needed help on a larger form, so decided to put the strategy to work there too. Here is the result. Not a pretty form by any stretch, but I was happy with how easily it all went together, and now getting me enthusiastic about going further with full blown form builder.

As an example, here's the PHP array schema for my test form:

$formArray = array(

   'personal_info' => array(
       'type' => 'Fieldset',
       'label' => 'Personal Information',
       'children' => array(
           'first_name' => array(
               'type' => 'Text',
               'label' => "First Name",
               'columnWidth' => 50,
               'required' => true,
               ),
           'last_name' => array(
               'type' => 'Text',
               'label' => "Last Name",
               'columnWidth' => 50,
               'required' => true
               ),
           'email' => array(
               'type' => 'Email',
               'label' => "Your Email",
               'columnWidth' => 50,
               'required' => true
               ),
           'phone' => array(
               'type' => 'Text',
               'label' => "Your Phone",
               'columnWidth' => 50,
               'required' => true
               )
           )
       ),

   'customer_feedback' => array(
       'type' => 'Fieldset',
       'label' => 'Share Your Feedback',
       'children' => array(
           'store_location' => array(
               'type' => 'Select',
               'label' => 'What store location did you visit?',
               'options' => array(
                   'ATL' => 'Atlanta, GA',
                   'CHI' => 'Chicago, IL',
                   'NYC' => 'New York, NY',
                   'SFO' => 'San Francisco, CA'
                   )
               ),
           'would_visit_again' => array(
               'type' => 'Radios',
               'label' => 'Would you visit that location again?',
               'options' => array(
                   'Y' => 'Yes I would', 
                   'N' => 'No I would not'
                   )
               ),
           'comments' => array(
               'type' => 'Textarea',
               'label' => 'Comments or Questions?',
               'description' => "We'll respond right away!",
               'rows' => 5
               )
           )       
       ),      

   'submit' => array(
       'type' => 'Submit',
       'value' => 'Submit Your Feedback!'
       )
   );

That schema can be converted to/from JSON just by calling json_encode/json_decode on it, and gives us exactly the portability I'd want out of it. Given that this can be translated to a full form of Inputfields with a tiny function (arrayToForm), I figured that's a great first step towards an interactive formbuilder. Here's what the template code looks like:

$form = arrayToForm($formArray);

if($form->isSubmitted()) {
   $body = "<html><body>" . $form->renderValues() . "</body></html>"; 
   $headers = "Content-type: text/html; charset=utf-8\nFrom: " . $form->get('email')->value;
   mail('me@domain.com', 'Form Submission', $body, $headers); 
   echo "<h2>Thanks, your form was submitted!</h2>";

} else if(count($form->getErrors()) {
   echo "<h2>Fix the fields in red and try again.</h2>";
   echo $form->render();

} else {
   echo $form->render();
} 

That's how I'm doing it now, but stuff like the above would obviously be integrated into a FormProcessor class so that you only need to call 1 function to display/process a form, and you could store and browse the results in a DB rather than just emailing it.

Inputfields need to be upgraded so that all the structural markup is customizable. I'd probably want the default render output to be structured around fieldsets rather than lists, and be something that one wouldn't necessarily need any prerequisite CSS/JS except for progressive enhancement. Other upgrades would be more validation options for the basic Inputfields. The nice thing is that any upgrades would benefit all of PW, not just the formbuilder. The next test/proof-of-concept will be to make the creation of that $formArray interactive from the admin (with a Process module).

[netcarver]

This looks great Ryan. If you take this a step further with the input formatting done in YAML or Neon then you'll have a super-terse way of defining your form structure.

[ryan]

Neon looks pretty cool! But will probably stick with JSON here, just because PHP has the built-in json_encode/json_decode, which are likely a lot faster than any alternatives (I'm guessing), given they are in C. While I wasn't familiar with Neon before, I also really like YAML. But until there's a native PHP function to encode/decode it, I'd rather trade verbosity for speed. We're still much better off than XML. Ultimately though, my interest in the format is for portability and copy/paste, rather than manual editing. The goal with the form builder is that people will define this stuff interactively rather than by typing code. But it is going to be really handy to be able to copy/paste an entire form definition from one site to another.

[netcarver]

Yes, using JSON would make transfer very easy. However, I was thinking that, just as with articles in textpattern that are written in textile and converted to HTML on save, the conversion from a YAML/NEON def only has to happen once, just when the structure is saved just after an edit. There is no need to trade verbosity for speed. If you stick with using the PHP-array to form conversion, then people can provide whatever front-ends for that they wanted, graphical (form building UI), compiled (from YAML/NEON), JSON or a straight PHP array.

[ryan]

It's not the encode I'm worried about (where speed doesn't matter too much). It would be stored as a JSON string, just like PW field/template/module settings. These are unique groupings of data that don't gain any value from being normalized, sortable or searchable. It just needs to be quickly accessible and decoded as a group. Similar to how WordPress and Drupal uses serialize() / unserialize() for this stuff. So the decode needs to be fast, but the encode doesn't. I suppose we could always store it literally as a PHP array, but then would have to eval(), which I try to avoid. Could also store as a PHP array directly in a file that could be include()'d and no decoding necessary.. but then I'd have to figure out how to encode an array to a PHP array string, and not really sure how to do that.

[netcarver]

Since Ryan posted that his prototype idea for a PW form builder I've not done much in this area. Rather than have the code sat under-utilized in a private repo I've now posted it as the fxForm repo under my github account in case anyone is interested. Currently you need the controller-element branch to get the latest code.

[teppo]

Now that's what I'd call "perfect timing." Was just about to start building some forms-related templates, now I guess I'll give this a try first

Just a quick question, @netcarver: how stable would you stay that this code is at the moment? Is it usable for a simple project already or more like "something you can try but don't count on it working" -- or something inbetween those options?

Edit: I did notice that "experimental" line in your README, but I'm still asking.. different people do have different meanings for stuff like "beta", "alpha" and "experimental", so..

Edited May 25, 2012 by teppo

[netcarver]

Hi Teppo,

I wouldn't consider it 100% stable just yet, and I've not touched it for about a month. That said, most of the features are fixed because the DSL takes its shape from HTML syntax and, if anything, there will be additions of helper functions rather than changes to existing ones. There are some major portions that need work and there is no upload ability in there yet.

If you are thinking of putting this into a client site I'd err on the side of caution. You can also ask Apeisa for his experiences with it as I know he started using it recently.