| Previous · Next | |
| User | Message |
|
patspam
|
Date: 4/14/2009 12:20 am · Subject: Thoughts on a 8.x form field library · Rating: 0
For the 8.x forms API rewrite, it'd be great if we built up some sort of Javascript form library, that is, something that we can use consistently for front-end input validation, fancy rendering, etc..YUI doesn't include much in the way of form validation, so we'd either need to build up our own library or take advantage of an existing open source project built on top of YUI. One such library is inputEx[1] (MIT licensed) which was featured a while back on yuiblog. The examples page shows the full suite of pluggable form field types supported. Using a library such as this would give us not only attractive rendering of the commonly used form fields and consistent validation handling, but also access to more sophisticated javascript-powered form fields. Each WebGUI::Form class would:
[1]: inputEx is the best YUI forms library I've seen, but it's a pure-javascript library. If we decided to go with it we would need to handle the progressive enhancement ourselves. One way to do this would be to apply the technique I used for YUI Nav graceful degredation. Alternatively, we could work with the inputEx guys to build it into the library itself (some of the more advanced fields might need to be flagged as javascript only if we can't find a natural html-only equivalent for them, at least until HTML 5 arrives..) |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 4/16/2009 1:05 pm · Subject: Re: Thoughts on a 8.x form field library · Rating: 0
For the 8.x forms API rewrite, it'd be great if we built up some sort of Javascript form library, that is, something that we can use consistently for front-end input validation, fancy rendering, etc.. 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. YUI doesn't include much in the way of form validation, so we'd either need to build up our own library or take advantage of an existing open source project built on top of YUI. One such library is inputEx[1] (MIT licensed) which was featured a while back on yuiblog. The examples page shows the full suite of pluggable form field types supported. Using a library such as this would give us not only attractive rendering of the commonly used form fields and consistent validation handling, but also access to more sophisticated javascript-powered form fields. 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. Each WebGUI::Form class would:Some form controls will not and can never be safe without javascript. But yes, I agree in general we should strive for this, and for the most part we already adhere to this. Yup. Provide an example please. 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. [1]: inputEx is the best YUI forms library I've seen, but it's a pure-javascript library. If we decided to go with it we would need to handle the progressive enhancement ourselves. One way to do this would be to apply the technique I used for YUI Nav graceful degredation. Alternatively, we could work with the inputEx guys to build it into the library itself (some of the more advanced fields might need to be flagged as javascript only if we can't find a natural html-only equivalent for them, at least until HTML 5 arrives..) 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. 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. JT Smithph: 703-286-2525 x810fx: 312-264-5382 Create like a god. Command like a king. Work like a slave. Attached Files |
| Back to Top |
Rate [ | ]
|
|
patspam
|
Date: 4/19/2009 11:30 pm · Subject: Re: Thoughts on a 8.x form field library · Rating: 0
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). 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:
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 |
| Back to Top |
Rate [ | ]
|
