How to render HTML fragment using metadata using DD4T

Question

Our current implementation is having different form displayed on the website.
These forms are displayed as HTML widget i.e. AJAX request is send to sales application, which returns HTML fragment. This HTML fragment is nothing but initial screen of the form. But due to latency at sales application we are facing following issues.

1. Entire page takes 8-10 seconds to load

2. Html the form is placed in middle section of page so till the time form is loaded footer section is displayed for few seconds and once form is loaded footer section scrolls down, this gives annoying user experience.

3. Sometime user click on footer links (till the time html form is loaded) and goes to next page considering there is no content on the page.

CMS implementation:

1. Empty div (place holder) is published from CMS side.

2. Using AJAX call on page load sales application is called

3. Sales application returns forms as HTML Widget.

4. Inner text of placeholder is replaced runtime to show the form.

To overcome this issue we are thinking:

1. Introduce a schema with RTF Field which will contain form html (first screen) .

2. 9 different components will be created using this schema.

3. Each component will have unique metadata key to identify which form it is.

4. At content delivery side using metadata key respective component presentation will be retrieved and displayed on page.

Is there any other better way to implement it?

We are using DD4T JAVA in current implementation, we can put form html in views but we need it to be managed through CMS.

Answer 1

Schemas/Components with RTF fields should NOT be used for forms, that is not a correct way forward. Whatever you store in he CMS should be content, and a form is not content, it is HTML.

What would be a better solution is to define a Schema that lets you build a form, so that the XML (of the Component) would contain a description of the form so to speak. Then your views should build up the form HTML based on the definition.

But when going that route, I'm still wondering if you won't be confronted by your badly performing sales application at a later stage. Since I gather you do want that to still handle the form post and generate/return a result. So I'm actually wonder if rather than building this workaround, you should invest some time in trying to make your sales application perform beteter and keep the solution as is...