Forum OpenACS Development: General Comment editing issue

So, I fixed the general comment page, and as a result found a problem which is located in core:

If you do something like...

db_multirow mu st {
  select
    f.foo, 
    f.bar
  from
    table f
}

(notice no code block) then the vars foo and bar will appear in the multirow and NOT leak into the template stack frame, so if you've done [set foo something] beforehand, foo will retain its value because the copy of foo altered by the query will not change the copy of foo that you would have set before the db_multirow call.

BUT

if you add a code block, like this:

db_multirow mu st {
  select
    f.foo, 
    f.bar
  from
    table f
} { 
    anything here, including nothing
}

then ALL vars (incl any defined in -extend) will leak into the calling frame.

This behavior is confusing, bug-causing and produces unmaintainability in other packages. It needs to be fixed as soon as possible.

Heya Brian...

Thing is, it's inconsistant. If you don't supply a code block, it doesn't overwrite the vars. If you do supply the code block, the vars "should" (IMO) only be visible within it. I didn't know about the unclobber thing tho. Looking at db_foreach, there's no such issue, or at least no "-unclobber" option. For consistancy's sake, it should be the opposite: if, on the small chance, someone wants the vars visible beyond the block, there should be a -clobber option, and it should also be in loops like db_foreach.

If you like, you can apply the concept from "Apple User Interface Guidelines": don't make (the programmer) remember any more than he has to, certainly not: "so there's a foreach, a db_foreach, a db_multirow, and in only one of those, vars are clobbered outside a supplied block, and then only when it's supplied"... nightmarish... That's exactly the kind of thing that's going to chase devs away.

-Jim

Actually unclobber only works if the variable was previously set. If it was not set before the multirow it will not be cleaned up after the multirow so you end up with new variables.

This makes it tricky with using template::list since naturally you want the filter names to match the varaible the filter is filtering for, and if the filter is not set, it will be set at the end of the multirow causing the filter to be applied incorrectly.

hmm. in that case it's not inconsistant... ok, never mind :)