Forum OpenACS Development: Re: Proposal for hooking forms to metadata

Collapse
Posted by Don Baccus on
We implemented customized .adp templating for scripts for Greenpeace, but not in a general way.  The only barrier to doing something general is deciding on just how we want it to work.  For GP we searched first in a custom location then used the existing paired .adp file (index.adp for index.tcl for instance) as a fallback, that way subsites only need to customize those templates they actually want to change.

But in the general case I'm not sure how it should work.

Regarding object types as objects ... Barry, could you e-mail me a tarball of your changes and (hopefully) update scripts to take a look at?  As I said above I do agree that this would be useful, and yes, permissions are why.  We were looking at this in the design of a "general ratings" package (that hasn't been implemented as the volunteer got a real job, a never-ending one because the company's using Java.)  The idea was that rating dimensions were to be ACS object types, and if these types were objects you could control who could rate an object using a particular dimension (rather than just "user can rate all aspects of a particular object")  The volunteer had a lot of experiences with knowledge management systems and had found that level of granularity important in the past.

Anyway ... I'd love to look at your object-types-as-objects changes.  4.7 is the perfect place to slide in fundamental changes of this sort.

form templating vs. ad_page_contract.  When I wrote ad_form (have you played with it?) I considered trying to do a tight integration with ad_page_contract but decided against it for the time being.  There are several reasons for that.  Among other things pages handling multiple forms aren't uncommon, so you want more than one ad_form call for the separate forms. And individual forms frequently need to be built piecemeal, this the "ad_form -extend" construct to add to an existing form.  On the other hand ... ad_page_contract sets a contract for the page and should be a one-call device.  Also errors are returned in an entirely different way by the form builder (ad_form) and ad_page_contract.  And ad_form handles the flow of processing self-submit forms for you in a way that's straightforward but doesn't blend in well with the ad_page_contract paradigm (IMO)

These aren't simple design issues to solve, so I decided to keep ad_form and ad_page_contract separate.  At the moment I think it would be a lot easier to document how the two interact.