I have been trolling the bboards, and I am impressed at how well
OpenACS-4 is coming along! I have one concern about something that
might impede future development though, and would like to get some
feedback on a possible solution I have been thinking about.
The old style of writing a db query (but using the db-abstraction) in
a tcl page went something like:
db_1row query_name "
select u.first_names,
u.last_name,
s.something
from users u,
something_tbl s
where s.user_id = u.user_id"
And similarly for db_foreach, etc. In these statements, the variables
first_names,
last_name, and
something are all
implicitly being declared and defined by the db-abstraction proc. One
is free to use them later in the tcl page.
However, what we are going to see soon is something like:
db_1row query_name
The tcl code following the query will still use the variables that are
implicitly declared, but by examining a tcl page, there is really no
way to know what variables have been declared for use by the db proc.
We could encourage
people to put comments around their db calls, but comments may become
incorrect if someone updates a sql file but forgets to update the
comments in the tcl file.
I read that Don Baccus was planning to clean sweap out the sql
portions of the tcl files once the porting is completed. I would like
to instead propose that the old sql code be replaced with a small
contract, so instead of leaving only:
db_1row query_name
which describes nothing of the implicity declarations taking place in
the db proc, we instead can have
db_1row query_name {first_names last_name something}
This way, there is still something left in the tcl file that both
describes what variables are availabe after the db proc executes, and
also describes what is expected of the sql code in the .xql file.
Additionally, one could invision somewhere down the road a code
checking tool that compares the sql contract in tcl code and sql code
in a .xql file and alerts you when they are out of sync.
Some things I would need other's input on:
- Should the contract to go both ways? IE, should bind variables
also be part of the contract?
- Does this make programming more tedious, or more clear?
Personally, I see it as writing more self-documenting code, much as
ad_page_variables was much better at self documenting than
set_the_usual_form_variables was.
- anything else someone can think of.
Comments please.