Domingo, your solution addresses the obscurity of variables, but I
don't think it's a good solution for a couple reasons.
- The query dispatcher is already a reality. Questioning its
existance seems, at least to me, to be a moot point already. My
proposal will still work with the query dispatcher as-is (it already
ignores the second variable passed to a db-proc, which it can continue
to do unless we want contract enforcement), whereas your script
solution calls for a large change to the acs-core.
- Having vestigial sql code in tcl files will be extremely error
prone. For your solution to be viable, programmers should not be
allowed to edit the tcl files to fix sql code. They would still have
to edit the .xql file, and then run a script that would update the tcl
file. I can envision people accidentally editing the tcl file and
then obliterating their changes when they later run the script.
So I'm still keeping the same proposal of a short contract in the db
proc that in essance is little more than an enforced comment. The
decision to keep tcl and sql code separate is a good one, but there
does need to be some level of obviousness in the tcl logic code as to
where variables are coming from.
The system as-is is fine for porting, but it will be a nightmare when
writing and debugging new modules, which I think we can all agree, is
what will determine the longevity of OpenACS. Having to ask questions
like "which file am I allowed to edit?" or "where did
that
variable come from?" will make it very unapealing for people to
develop new modules.
