Forum OpenACS Q&A: QD unable to properly map <acs root>/tcl/*.tcl files

This maybe a dumb question.

Anyway here is the problem

placing the files in /tcl/file.tcl and /tcl/file.xql does not seem to
work very well.  Since QD looks for the complete query name or some
sort.  The procedure db_qd_get_fullname encounters an error wherein
$rest has no value.

Moving the /tcl/file.tcl and /tcl/file.xql to
/packages/some_package/tcl and making the appropriate changes to the
APM admin things start to work.

I know it might be dumb but cant you use /tcl anymore for doing
queries?  What if I just want to test a simple script file and this
script has no real package yet.

Do use /tcl, use any other packages or create your package?

I am coming from ACS 3.x so /tcl seems to be my first try when I want
to try some Tcl files that get some simple queries.

Please give me insights to this behavior.  Thanks.

That directory is really supposed to be empty except for the two files
you see there in the distribution.  This is a major change from 3.x, indeed.

Just guessing off the top of my head, the problem probably isn't the query dispatcher, but the code that loads query files.  It depends on the routine that determines a file type from its path and extension, and this code is probably ignoring the global tcl library directory.

That's *just* a guess, though, not verified by reading the code.  I'm mildly opposed to making this work anyway ...

Hi Dan,

You are right in opposing in working on /tcl global dir.  What would
be the suggested way to test / start a package?

1. drop your test Tcl files to any package.  Not very good but gets
your started.
2. Start a skeleton package.

Is there a skeleton package?

I would be great if we can compile a doc/faq on best practices in
customizing OpenACS sites.

Right now I can contribute to the doc/faq although not in the
development side since I am kinda new to 4.x.  I can contribute my way
of setting up multiple ACS in box.  Scripts to automate some stuff,
etc.  The real world stuff that I have learned after installing ACS
again and again.

Maybe I would start another thread like "Real world practices on
running multiple ACS sites in a box".  Would that help?  If this helps
it would be more helpful after the threads activities it will put into
a doc/faq.  What do you think?

Too tired now.  I will probably start it tomorrow, maybe after your
feedback.

Jun

Well it could be considered either a bug or feature depending on how you look at it, but you can make it work by change the regexp code towards the end of db_qd_get_fullname to the following:

	# We get something like packages.acs-tcl.tcl.acs-kernel-procs
	# We need to remove packages.
	if ![regexp {^packages.(.*)} $url all rest] {
            set rest $url
        }

The regexp assumes that the .tcl file is always below the packages subdirectory, which is not correct for the root level tcl directory.

The above won't completely fix the problem.  As Don mentioned, the xml file doesn't get loaded correctly either.  It shouldn't be a problem to fix though, if we want to turn this into a feature.
Ok I do agree that the global /tcl should not be used too often anymore.

Either create a skeleton package and put it your tcl files there or
hijack some package for testing.

We should end this thread now but can I make a request on the OpenACS
team.  In the global /tcl directory can we place something like a
README.TXT stating the QD will not be able to properly dispatch the
queries from here.  Probably even stating to avoid using the global
/tcl dir.  This will help others not to waste their time further why
things are not running well.  Thanks.

That's a good idea, yes ...

Tell you what - if you write one up quickly and e-mail it to me, I'll add it.  How's that?