Hi,
I am not totally against Dirk suggestion to on not to use tcl proc to do database work. But I took the other route of using tcl proc to do database work. Upon getting some suggestion and indication that is the path to go. I decided to go that way. Here are the pros and cons I have encountered:
- makes it life harder for the one making the tcl proc. You have to think about what to make and how to present it.
+ makes life a lot easier for those who will use. they don't have to know the lower layers.
+ make one object manipulation a lot easier. that is add, edit and delete.
- makes listing of objects harder. I have actually decided that the listing of objects be only used for preliminary development or basic behaviour. the end developer should just use the query as reference and create his own select based from the reference query.
+ optimizing or bug fixing becomes easier, as once the tcl proc is fixed. code that uses it get fixed too.
- as more people/code use it. you will have to more and more worry about compatibility.
- added burden for you to review your code. which tcl proc to merge, split, bad presentation, etc.
Anyway I hope the following info may help both group people looking at moving db work to tcl AND moving db work away from tcl.
I think given that there are many of us, its likely we will have different opinions. The OCT should be able to give direction what is best of OpenACS in general.
I am not yet completely sold to the idea of moving db work to tcl proc. But so far I think for my current use despite the negatives, I value the positives more from what I got from it.
