Content Editors & Forms
We often get feature requests to support forms. Unlike other features, forms present several challenges.
From a technology perspective, forms generated by XStandard would need to be standards compliant / accessible. Just dragging/placing controls in a WYSIYWG environment wouldn't do. The user would need to associate every control with a label as well as provide additional metadata in order for forms to work correctly on a Web site. Also, most users would want to use layout tables to arrange the form which is not the best approach.
From a user perspective, users get certain expectations when they create forms. They expect them to work right way. Non-technical users may not realize that server-side processing is required.
Another alternative is to use placeholders for forms. Placeholders are custom tags that reserve space for dynamic content. For example <login /> or <feedback title="Placeholder for feedback form." />. See screenshot / example. The user can select placeholders from a library and position them anywhere in the content area. You can also set it up so that in Preview, the form is actually displayed. When the Web page is generated, server-side scripts replace placeholders with the markup for the form. So, users have control over which form to use and where to put it, while admins have control over the contents of the form.
A live example of placeholder replacement is available on the Download page on our site. To see the markup behind this page, click on the link "View XML for this Web page" at the bottom of the page. You'll see a placeholder <download />". When the page is generated, <download /> is replaced by the markup for the form.
We need more feedback on the use of forms. Should forms be supported or are placeholders the way to go?
Last edited by Vlad Alexander on 01 Feb 2005 08:37 pm; edited 1 time in total
From a technology perspective, forms generated by XStandard would need to be standards compliant / accessible. Just dragging/placing controls in a WYSIYWG environment wouldn't do. The user would need to associate every control with a label as well as provide additional metadata in order for forms to work correctly on a Web site. Also, most users would want to use layout tables to arrange the form which is not the best approach.
From a user perspective, users get certain expectations when they create forms. They expect them to work right way. Non-technical users may not realize that server-side processing is required.
Another alternative is to use placeholders for forms. Placeholders are custom tags that reserve space for dynamic content. For example <login /> or <feedback title="Placeholder for feedback form." />. See screenshot / example. The user can select placeholders from a library and position them anywhere in the content area. You can also set it up so that in Preview, the form is actually displayed. When the Web page is generated, server-side scripts replace placeholders with the markup for the form. So, users have control over which form to use and where to put it, while admins have control over the contents of the form.
A live example of placeholder replacement is available on the Download page on our site. To see the markup behind this page, click on the link "View XML for this Web page" at the bottom of the page. You'll see a placeholder <download />". When the page is generated, <download /> is replaced by the markup for the form.
We need more feedback on the use of forms. Should forms be supported or are placeholders the way to go?
Last edited by Vlad Alexander on 01 Feb 2005 08:37 pm; edited 1 time in total
[off topic pet peeve]
[edited and removed]
=========
Now onto the subject at hand, I recently revisited the phpFormGenerator pages and wondered whether any of that would be of use to you?
The output is almost certainly tabled at present, but that could be altered fairly easily.
Anyway, placeholder or not. Well because of the difficulties that you have mentioned in creating a form I'd go for a 'separate' sub-interface for the creation of forms that can then be placed into a page. It might be able to be done on the fly, and all the code transferred, or it could refer to a selection of forms, [form1] etc.
I can see problems with either method, but I think the 'placeholder' is slightly better. That way you can control the interface required to create, and manipulate, the form in the first place.
I think
Last edited by Rich Pedley on 01 Feb 2005 09:03 pm; edited 1 time in total
[edited and removed]
=========
Now onto the subject at hand, I recently revisited the phpFormGenerator pages and wondered whether any of that would be of use to you?
The output is almost certainly tabled at present, but that could be altered fairly easily.
Anyway, placeholder or not. Well because of the difficulties that you have mentioned in creating a form I'd go for a 'separate' sub-interface for the creation of forms that can then be placed into a page. It might be able to be done on the fly, and all the code transferred, or it could refer to a selection of forms, [form1] etc.
I can see problems with either method, but I think the 'placeholder' is slightly better. That way you can control the interface required to create, and manipulate, the form in the first place.
I think
Last edited by Rich Pedley on 01 Feb 2005 09:03 pm; edited 1 time in total
Placeholders would certainly work for me. The forms our content editors use are almost always simple frontends onto backend functionality that I've built for them. They get told the form action, method, fields (required and optional) and away they go.
I can appreciate the difficulties they present you for standards compliance / accessibility, but forms support of some form (!) is a must-have feature for some of us.
I can appreciate the difficulties they present you for standards compliance / accessibility, but forms support of some form (!) is a must-have feature for some of us.
I use PHPFormGenerator all the time for my Forms... but yea the resault is all tables, empty tags are not closed, many "" are missing from attributes.....
The PHP is good but the output is horrible and needs alot of work to validate as any form of XHTML and be called accessible as well.
--
[size=9]Kyle J. Lamson
Analyst/Programmer III, State of Alaska
The PHP is good but the output is horrible and needs alot of work to validate as any form of XHTML and be called accessible as well.
--
[size=9]Kyle J. Lamson
Analyst/Programmer III, State of Alaska


