Forum OpenACS Q&A: Re: Greenpeace: Pay up!

Bruno, I already said I'm sorry for bring Greenpeace into it. That was a mistake based on the fact that the documentation and source code for ad_form both mention Greenpeace. Also, it is no secret that Don developed it while working with Greenpeace specifically for his work on the Greenpeace sites.

The fact that ad_form can be understood by reading the source code is irrelevent to my argument. You represent a relatively large organization that can afford the best available developers, and you do afford them. Your orgainization has brought quite a lot to OpenACS, to the toolkit and the community. Thanks for that.

The problem I am having with ad_form is a result of it's uselfulness. People are using it. ad_form is enabling the use of the underlying form builder. It didn't matter that the form builder was underdocumented, it was really too hard for most developers to use. ad_form has enabled the use of this underdocumented part of the toolkit, which in the end really requires that you understand the form builder.

Now being a large organization with sufficient funding to maintain your web applications doesn't give you the same perspective as a small organization would have. If you need to debug a single page, or extend the toolkit in a simple way where ad_form has been used, now the problem starts. Instead of simple job of understanding the traditional tcl/adp page series, you have to figure out stateful pages that go through several underdocumented layers of api code.

I have yet to run into this issue, I admit. But I see more and more use of ad_form, some in core applications, because it speeds up development, or so it seems.

Next, I guess it a difference in development styles. ad_form uses widgets to generate html code. All the examples I have seen just have the formwidget tag on the adp template page. When I write adp pages for a tcl file, I like to "document" what varibles are being used, by using them. Then the next time I visit that page to fix some problem, I know what I need to do. When I read an ad_form page, and the adp template, I have very little idea what variables are available to use. In order to make a change, I need to understand ad_form and the form builder.

The ad_form code is understandable, but it isn't the kind of code that should be generally read by developers, unless they find ad_form doesn't do what they need and they want to extend it.

So, again, my concern is that ad_form is being used more and more, in some cases in the core of the toolkit. These changes are being made by folks who understand ad_form. But now everyone who uses these packages really needs to understand it, and form builder, as well. The traditional approach of setting up data sources in the tcl page and then providing markup on the adp pages is mixed up with form builder and thus ad_form. The inevitable result is that changes which could have been done by graphic artists, and html editors, now requires the work of the tcl programmer. This means that the toolkit will be harder to adopt by newbies and more expensive to maintain.