Forum OpenACS Q&A: Response to Using [Incr Tcl] to generate OpenACS code
general I've spent time thinking about autogenerating of package
components. Yes, it would be good to have though specifics need
discussion (so I'm glad you've raised it here).
We also want to incorporate simpler generation of service contracts, too.
As far as forms go, as I've mentioned elsewhere I've been working on a
form-building counterpart to ad_page_contract which I'm calling
"ad_form_prototype" at the moment. It's in the development branch.
I'm using an extended version heavily in a client application at the
moment, and it's a great help.
Doing forms via separate pages and ad_page_contract isn't the "right"
approach, but rather the form builder itself should be used to
validate input. Doing it this way results in the errors being
embedded in the form, a user-friendly thing to do.
My "ad_form_prototype" allows you to build form handlers in a
declarative style, and handles key management and event management
(request vs. submission, edit data vs. new data, etc) for you
automatically.
The weakness of this approach is that it inherits the weaknesses of
the form builder (it uses it as a back end, so to speak). This means
that data validation is weaker than in ad_page_contract at the moment.
The fix for this is to strengthen the underyling form builder in this
regard, rather than abandon it. I've got a laundry list of minor
improvements to the form builder that I want to make which will make
the "ad_form" approach even better.
The form I use for my current client project also handles submits from
javascript which are meant to refresh, rather than process, the form.
John Mileham of the Berklee School of Music has changed the form
builder itself to handle these and when I get some time I intend to
meld the two. Whether or not one personally likes Javascript widgets
the fact is that clients sometimes demand them and we need to have a
clean way to handle them.
The CR and CMS also have built-in tools for dynamic form generation,
which includes the ability to attach widgets to attribute types and
attributes (the latter overriding the former for a particular
attribute, if given) and output templates for content types. Since
most find the CMS UI inpenetrable few have poked around into the
internals to see what's available. These pieces are candidates for
building a toolkit-style package for building content-handling
application packages.
The folks at InfiniteInfo have been looking into the CR/CMS stuff in
their spare time.
I've already posted in the past in regard to ad_form. Some of the
other stuff above's been discussed in e-mail, primarily as a courtesy
by folks like InfiniteInfo and Berklee who let me know what they're
working on so I'll know who has expertise and code to share for
various things. When (if? hopefully when) folks like Berklee get
their heads above water in regard to their day jobs, we'll have some
real world experience with various of these pieces that can form the
basis for discussion on how to best improve the template and form
builder engines to suit our needs.
