Forum OpenACS Development: bt_mergepiece?? Templating

Posted by Gilbert Wong on
What is bt_mergepiece?  It doesn't exist in ACS 4.x but it does exist
in ACS 3.x.

Also, I noticed that the simple survey module uses templating in the
user accessible pages, but it does not use templating in the admin
pages.  For the postgresql port, I will just do a straight port.
Once I finish the postgresql port, I will make the admin pages
templated.  Does this approach seem reasonable?

Posted by Ben Adida on
I hope Philip sees this thread :) bt_mergepiece is probably one
of the oldest utilities written for AOLserver. It was originally
written for Naviserver 0.9 by Brian Tivol (do the initials bt make
sense now?) when Philip, Brian, and I worked on the Hearst
New Media site (now dead) in 1995. I
rewrote it to be somewhat more efficient in 1996-7.

What does it do? It takes two arguments: a big chunk of HTML
that contains a raw form, and an ns_set that should be a bunch
of values for the fields in the HTML form. Usually, the ns_set
comes from a ns_db 1row query. The output is a chunk of HTML
that is exactly like the original chunk except that all vars in the
form now default to whatever values were in the ns_set. It works
with text fields, textareas, drop downs, radio boxes, etc... Pretty
useful stuff, but not exactly super efficient.

Posted by Gilbert Wong on
Thanks.  I took the code for the procedure from OpenACS 3.x and put it in the survsimp-procs.tcl and named the proc survsimp_bt_mergepiece.  One or two of the pages use this procedure to preselect some radio buttons.
Posted by Ed Avis on
(This is very odd.  I posted a reply here this morning, but now it
doesn't show up in the page.  I will post it again.)

bt_mergepiece is a crusty bit of Philip code which takes in some HTML
containing <input> elements and marks some of them as 'selected'
depending on the value of Tcl variables.  Although creating forms with
the right things selected can be a pain, and it would be nice to
automate it a bit, having Tcl code munge already-generated HTML using
regexps is not the right way to do it.  bt_mergepiece has gone away in
ACS Tcl 4.2.

I have been doing some work on Simple Survey to use it with ACS 4.2 -
I replaced the call to bt_mergepiece and changed the user-visible
pages to use templating (at least for the header and footer).  I
released that version as 0.2.1 to the ACS Repository - since the
Repository's version number sorting is broken you need to 'show all

I have done some more work on it since then, adding the ability to
attach pictures to questions and answers ('do you prefer this picture
or that one?', 'please give your opinion on this photograph').  The
picture support uses a simple picture support package rather than
content repository, so it is a bit non-standard.  But I plan to upload
both the simple-pictures package and the picture-enabled Simple Survey
package when I've finished tidying and fixing bugs.

It would be sensible to cooperate on Simple Survey, assuming it's
possible to write a package that works on both ACS Tcl and OpenACS.
Or at the very least, you should take 0.2.1 as a basis for porting.

Posted by Gilbert Wong on
Ed - How extensive are the changes you made to version 0.2.1?  If the changes are minor, I'll go ahead and make them in the OpenACS version of the simple-survey package.  I have one more bug to fix until I can release the postgresql port of the package.

For the OpenACS Core team - Are we planning to keep the packages for ACS Classic and OpenACS as similar as possible?  Is there a point where we will fork the package code completely?


Posted by Ed Avis on
(I've been sending electronic mail to discuss Simple Survey, so this
posting is more 'for the record'.)

Basically 0.2.1 is bugfixes for 0.2 to make it work with ACS Tcl 4.2.
Removed the call to bt_mergepiece, used templating for the user
pages, a couple of other bugfixes.

I have a new version of Simple Survey, not yet uploaded to the
repository, which allows pictures as well as text for questions and

Posted by Don Baccus on
I'm sitting at a c@p site (canada public internet access site) in Nova Scotia, thought I'd check in to see what's up ...
<blockquote><i>For the OpenACS Core team - Are we planning to keep the packages for ACS Classic and OpenACS as similar as possible? Is there a point where we will fork the package code completely?

We are forking but will pick up improvements as they become available.  Since aD is dropping ACS Tcl development, consider this picking-up of improvements as a winding-down process.
Ed - OpenACS 4.x supports Oracle as well as Postgres, but the framework, with the query dispatcher and partially rewritten bootstrap installer provides a different environment than ACS 4.x Classic.  Sharing sources directly would only be possible if aD started using that framework.  We need to do performance testing of and most likely efficiency hacking on the query dispatcher before we could really recommend the new framework for a production environment.  It's still in pre-release form...

Posted by carl garland on
> I'm sitting at a c@p site (canada public internet access site) in Nova Scotia, thought I'd check in to see what's up ...

I am very jealous :) One of my favorite memories is when I took a 5 week motorcycle trip through northeast us and 6 canada provinces. My favorite part of the trip was Cape Breton in Nova Scotia. If you have the time be sure to take the whale cruise with the one armed captain it is well worth it. Also Moose lake in the highlands plateau often holds many a moose at the shores at night. Enjoy the view.

Posted by Ed Avis on
Update on Simple Survey: it's been a while, but I've put up a page detailing changes and new packages for ACS 4.2. This includes the updated, bugfixed, pictureified version of simple-survey. But it's an ACS Classic package and hasn't been ported to Postgres.
Posted by Don Baccus on
Ed has kindly provided me with several pieces of code including the improved survey simple package.  While it won't get ported into this round of releases (at least not the pre-test version) we'll make use of it before too long.