Forum OpenACS Development: Too much customization to use ad_form?

Collapse
1: Too much customization to use ad_form?
Posted by Iuri Sampaio on 04/05/18 01:03 AM
Hi there,

I have several HTML forms, structurally different (i.e. from element positioning & numbering to layout & design style sheets). Thus, functionality and look 'n feel play important roles "together", always.

Form's elements vary a lot, depending on the object, which the user needs to interact. So, label, values, data-types, widgets, borders, colors, placeholders, JavaScript validations, dynamically nested elements and widgets ...

The list goes infinite, and it's hard to tell if new ways to implement the form and its fields would come up. They probably will,

However, I'm a stubborn adult and I really want to use ad_form, acs-templating and all their benefits behind the scenes, and I've got stuck, trying to migrate them from pure HTML, CSS and JS into acs-templating.

I've tried to find my way out, reading lots and following OpenACS documentation but the tasks are still very painful, and sometimes just impossible to achieve the same results.

Am I on the right track? Is it really the best approach, to use acs-templating, for such customized, unsorted and mutable scenarios?

1) https://openacs.org/doc/acs-templating/
2) https://openacs.org/doc/acs-templating/tagref/formtemplate
3) api-doc/proc-view?proc=ad_form&source_p=1

Best wishes,

Collapse
2: Re: Too much customization to use ad_form?? (response to 1)
Posted by Brian Fenton on 04/06/18 10:50 AM
This is difficult to answer. OpenACS form builder is powerful (albeit dated) and delivers a lot. However, as with any framework, you are restricted to what it can do. If you need very unusual styling or element positioning, it may be possible that you have reached a limitation of form builder (I say form builder as I don't really enjoy using ad_form, as I find it less readable).

However, nowadays with heavy usage of JavaScript, it could be argued that there is less emphasis on a backend framework like form builder, and more possibilities to achieve your goals when combined with modern JS tools.

I must admit to being a little out of touch with the most popular web frameworks (node.js?) but I imagine their approaches are possibly quite different from how OpenACS works. That said it should be possible to create a "modern" website using everything in OpenACS.

(Vague answer to a broad question!)
Brian

Collapse
3: Re: Too much customization to use ad_form?? (response to 2)
Posted by Iuri Sampaio on 04/10/18 10:38 PM
Indeed, it's a broad question!

I agree that it's totally possible to create modern sites using OpenACS.
The main idea behind this post is, once again, to find ways to integrate frontend frameworks (JS based) with backend (OpenACS) more easily.

Thanks for your answer anyway. It has really helped to confirm my suspects about ad_form and even more important, you confirmed that I'm probably in the right path, understanding acs-templating pkg.

Best wishes,
I

Collapse
4: Re: Too much customization to use ad_form?? (response to 1)
Posted by Michael Aram on 04/10/18 11:47 PM
Hi Iuri,

I have just recently "upgraded" an HTML mockup with a nice looking form to a ad_form by simply

a) copy-pasting the HTML mockup "as-is" into the ADP file
b) only replacing the <form> tag by <formtemplate> and the input elements by <formwidget>.
c) adding a corresponding TCL file with an ad_form that has a simple element stub defined for each input in the form. (i.e. more or less only my_input_name:text(text),optional)

Because of the fact, that I have only used ad_form with empty <formtemplate> tags in the past (where the whole form look and feel is generated automatically), I was surprised how easy it was to get the basic functionality working. In order to provide server-side validation, I later added a handful of <formerror> tags here and there. There may be useful features of ad_form which can't be used when going this way, but for simple cases, it could be a first step for a migration.

What have you tried? What was the showstopper?

Collapse
5: Re: Too much customization to use ad_form?? (response to 4)
Posted by Iuri Sampaio on 05/03/18 08:57 PM
Michael, Showstoppers were TCL and ADP compatibility in a sense that ad_form didn't work hamoniously with plain HTML inputs declared in the ADP file. Matching ad_form -form elements (i.e. TCL file) with html input (ADP files) caused wether duplicity and overwriting conflicts or unawareness by ad_form. Plus, ad_form worflows didn't work as expected (i.e. edit_request, validate, on_submit, etc) As per your example, I can see now that the reason could be because I've tried b), replacing
by but without using . See example https://pastebin.com/fxGYn3dn I've used plain html inputs only. Then, I went to step c) and start coding the same html input in the ad_proc ad_form, hoping that it'd be enough to ad_form recognizes all those plain HTML inputs, present in the ADP file. That was my a mistake. Too easy to believe that would work :) I'm not familiar yet to acs-templating and formwidget tags. I'm going to get back to them, reshape ADP files, as per your example and share the results here. Thank you for sharing this case. It helped a lot to see a new perspective and how to use it, which I didn't even know it was possible. Best wishes,