There is no planned rewrite of the forms API in 8.x. The only thing planned is a refactoring to make it a little less obtuse and a little more automatable. Rewriting from the ground up just isn't an option. There isn't time for that in the schedule, and it would be a major migration effort for everyone with custom code on the current system. 

Ok, I see the wisdom in that.
 

The inputEx package looks great to me. Looks like a good jumping off point for adding better client side validation in a more consistent manner. 

Awesome. Although before I get too excited about inputEx, Kaleb has just pointed out to me that their A-grade browser support may not fit the current wg core policy:

Firefox 1.5+, Safari 2.0+, IE 7.0+, Chrome 0.2+ and Opera 9+

Note that IE6 is not in there. Can you comment? That might mean as part of matching up WebGUI::Form control types to inputEx field types we need to review which types are IE6 compatible (seeing as inputEx is YUI-powered, my hunch is that IE6 will be fairly well supported overall - perhaps we will just need to exclude some of the more fancy field types).

• be able to generate JSON data instead of HTML markup, for ajax-powered forms

Provide an example please.

I was slightly muddled, what I really wanted to say is that a wobject using inputEx powered WebGUI::Form would sometimes want to return JSON config data instead of asking WebGUI::Form for html. That is, so that a javascript UI could do an ajax request for form information, and the wobject only needs to return serialized JSON form config data (field types, validation info, etc..). This config data would then be passed directly to the inputEx js library which renders the form elements, applies validation etc..

Survey is an example of this - each "Continue" click currently submits the form and requests the next html string to inject onto the page, whereas with inputEx we would only have to return the json-serialized form config data.

I guess the only refactoring that might be nice would be to make it easy to pass around the same form config data for:

• serializing to json for the ajax scenario
  
• instatiating a WebGUI::Form control to generate the static html
  
• validating input server-side for a WebGUI::Form control

This is already mostly true, although this new javascript library is quite a bit fancier than anything we do now, so the server side stuff will need to catch up.

That should be pretty straight-forward given how much easier it is to write robust validation code in Perl than it is in javascript.

I'm all for contributing as many ideas and code back to the inputEx guys as they'll take from us. But they may not move at the same schedules and pace as us so we'll also need to handle it our own way as well.

Agreed. The main factor will be ensuring that we're using a version of inputEx that is intended for the same version of YUI that wg is using. I think they're working against YUI 2.7 now, whereas wg is still at 2.6. Beyond that, we can build our own elements, contribute back whatever they want to accept, fork their code off github and keep whatever schedule we like :)

All in all, I'm in favor of whatever we can do to improve form handling from the ajax side of things so long as we don't break API compatibility too much on the form control system (thusly causing a massive rewrite for everybody). There will be plenty of room to break absolutely everything in WebGUI 9, when we switch to Perl 6. That's going to require a ground up rewrite so we can make as sweeping of changes as we like. As for WebGUI 8, we have to make it as painless as possible for everybody.

Holy crap, did you just say that WebGUI 9 is going to run on Perl 6? You just made my day :)

Patrick