Forum OpenACS Development: Re: Berlin bug bash proposal
I'll post details about the place later.
My #1 priority for the code bash and for OpenACS 5.1 is to enhance acs-automated-testing. So all work for that, from the preparations to the deliverables at the end of the bash, should be in the form of checkins to the package on HEAD.
Pri A integration of tclwebtest into acs-automated-testing
A: simplify tclwebtest installation
A: better test categorization
use category package?
see related forum posting http://openacs.org/forums/message-view?message_id=150581 for some categories
B: define a test as a collection of other tests, in sequence
B: macro test recording
B: UI to turn on macro mode
B: basic recording: when you fill out a form while macro mode is on, the submit is caught and displayed as tclwebtest code, and then executed
B: UI for creating aa_true tests automatically, based on the content of the page. (For example, a form that says "the returned page must contain [ type regexp here] that spits out aa_true "test X" [string regexp blah blah]
Depending on who attends (Timo, Dirk?) we could put Category on the agenda, where the work would be:
# UI to manage categories. This is fully implemented in the current package (but may use custom kernel code, so we would have to refactor)
# Documented code snippet to add to any OpenACS object's UI to associate the object with categories. (This is analagous to putting an "add/view comments" blurb, as documented in General_comments in Advanced Tutorial). As far as I know, this is not done.
# Documented code snippet to display category info per object. Also analagous to comments. Also not done, AFAIK.
# By adding a flag to list-builder, automatically filter objects by category. Not implemented.
with it. From brief code inspection it seems that the module currently is an
open and warm invitation to forking: It requires a table that holds object
names and probably also uses the redirection trick Timo and I have talked
about, so if you want to use this package you need to change "categorizable"
It may be a good opportunity for the OCT to take a decision: it is an
interesting module, but currently defies two major design principle of OpenACS
4.X/5.X, namely it doesn't come with upgrade scripts and it leads to every
individual programmer fork in a different way.
On the other hand I strongly dislike the idea of enforcing a technical
solution only to make some other solution work - especially given that above
table and redirection trick doesn't seem an issue to enough people.
And we haven't come to a conclusion yet on how to work on all of this - guess
I lost some interest in battling electronically in the past weeks.
There'll be some sofas and wlan, and most likely a beamer for spontaneous presentations.
Please mail me if you are going to attend so that I can plan ahead and can send you some more details.
Being an OpenACS novice, I will probably be something between a Worker Bee and a fly on the wall.
When should I aim at being there?
Timo, Branco and whoever else coming from Munich: My flight back (TXL-MUC) is LH237 (Feb 15, 21:15)
not 21 as I posted above, sorry about that. You can use e.g. www.stadtplandienst.de for a map. I would post a direct link but I think they don't allow that. When you come from S-Bahn station Hackescher Markt you walk down Oranienburgerstrasse, then turn left into Monbijoustrasse just after the park, and then to the right again into Ziegelstrasse. The bootlab is the first door on the right side in that street.
I would suggest we don't start before 11h.
So far I have the following list of people who plan to attend - could those who are in confirmed but don't come or those who come but are not in confirmed post here or send me a mail please so that we have a better idea of how many people will come? Thanks!
There'll be wavelan and ethernet. Does anyone _not_ bring his or her own laptop and needs a computer?
My phone is +49-175 904 5055 just in case.
A: discuss solutions to named objects archictural problem and produce TIP for voting
details (corrections welcome, of course):
The category package reveals a flaw in the OpenACS architecture, and instead of working around it in category, which is problematic, we should address it head-on. Using category as a use case, here is the problem:
Some use cases for categories involve showing a list of openacs objects, such as all objects in a category. In order to display such a list, the OpenACS core API provides for acs_object__name for each object, which is actually several layers of abstraction in both SQL and TCL. However, the performance is unacceptable and this is probably a structural problem. We also need a URL for each item, and the OpenACS core API does not provide for this.
Category solves this problem by creating an acs_named_objects table. This is a denormalized table containing object names. This table is empty, however, and the details of filling it will vary by package. Thus, anybody who installs category cannot use functions that use this table unless they also change every other package in OpenACS.
Category solves the URL problem by "using /o/OBJID to defer URL lookups. so it's ok if its a slow function lookup since it's only done one object at time when someone clicks on a link" (jcdldn).
Solution 1: Make acs_named_objects a core table; document the work required per package to populate it; do this work for the core packages.
Solution 2: Today packages create their own implementation of acs_object__name which is called by acs_object__name. The value of this function is typically something package-specific, or something trivial like "Object #123456". Packages should have triggers on the table where the data ultimately comes from that update acs_objects.name or acs_named_objects, in lieu of true functional indexes on acs_object__name. (guan)
- Requirement 3, tests which are ordered lists of other tests, can (maybe) be done already simply by calling other tests from within one test. If you can't invoke a test from within another test now, should we hack that in? Would that then be enough to cover all of tammy's case for reusing setup/teardown procs etc?
- Is the (new and improved) catalog file functionality for translations something we can use for automated tests? If we have a public test server where anybody can submit a new test, we have basically the same sync problems as on the public translation server.
- Do we need to use the category? Is it ready?